When implementing OAuth in Intuit Anywhere, I get 401 Unauthorized (Signature Invalid) error while requesting request token.
I am sure that I have implemented my signature part correctly. I verified it with the result of an available tool as well.
I have included oauth_callback also in my signature generation apart from other oauth_* parameters.
Intuit Anywhere asks for certain URLs like application URL, disconnect URL, manage users URL. What is the significance of these URLs?
I am trying to develop a non ui application which would consume IPP's data services.
Lalit, there's documentation on those fields you are asking about here.
On the OAuth request part, if you update your question with an example of your query parameters and signature I may be able to help.
Lalit,
A couple of avenues through which you could reach out to the Intuit team -
Post questions and read feedback in our developer Support Forums -
https://idnforums.intuit.com/
Submit IPP Developer Relations Support request -
https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0100_Support/0010_Submit_Support_Incidents
Related
I'm trying to learn about OAUTH and OpenID Connect.
Thus I am investigating my own traffic, listening to Authorization Requests and Grants by checking for required parameters in OAUTH as described in https://www.rfc-editor.org/rfc/rfc6749#section-4.1.1 and https://www.rfc-editor.org/rfc/rfc6749#section-4.1.2 for the Authorization Code Flow as well as described in section 4.2.1 and 4.2.2 for the Implicit Flow.
Unfortunately, by using the SSO option for Google on joinhoney.com, I am only able to catch the Request, but not the Authorization Grant.
So, while debugging and having a look at the actual request, I can see the following parameters in the query part of the url:
Parameter
Value
redirect_uri
storagerelay://https/www.joinhoney.com?id=auth[censoredID]
response_type
permission id_token
scope
email profile openid
openid.realm
client_id
705229005811-2fdpup66d8aefq4qs2ru1n8qiosuq4fb.apps.googleusercontent.com
ss_domain
https://www.joinhoney.com
fetch_basic_profile
true
gsiwebsdk
2
Now, to get to the actual question:
Where can I find some specified information about the ss_domain parameter?
I could not find any information in https://www.rfc-editor.org/rfc/rfc6749 as well as on https://openid.net/, however when using google, I can find some people using the ss_domain parameter (only without further explanation), so I doubt it is something only used by joinhoney.com.
Would be happy if somebody could bring some light in here!
Thank you!
If you are at www.example.com, and you your redirect_uri is to a different domain e.g. subdomain.example.com, you need to set ss_domain to https://subdomain.example.com.
This custom ss_domain change, however, is not possible using the Google login client side sdk. You got to push the url manually.
I'm integrating to Google OpenID Connect as a relying party, using the authorization code flow. If I send in an invalid parameter in the AuthenticationRequest, e.g. an invalid value for scope, Google presents the error in a web page saying e.g. "Some requested scopes were invalid...".
The OpenID Connect spec (and the OAuth spec) clearly states that: "Unless the Redirection URI is invalid, the Authorization Server returns the Client to the Redirection URI specified in the Authorization Request with the appropriate error and state parameters."
Am I doing something wrong in my request, or am I misinterpreting the specification, or are Google just not conformant when it comes to sending error responses?
Sounds to me like Google is a little non-conformant here:
Step 10 of my blog post shows the standards based behaviour
As a developer of an OIDC client you need to accept that some invalid input will be displayed in the browser:
Invalid client_id / redirect_uri
I tend to use an invalid scope to test error responses - it is handy for that - and I guess you're doing the same.
Solutions from the big cloud vendors often have this type of annoyance - when all that we want as consumers is a standards based solution.
I can't figure out if oAuth 2.0 server should revoke old Authorization Codes (not Authorization Tokens) when new code requested? Also I can't figure out in what format oAuth server should show the error if valid redirect_uri parameter not specified neither registered in app settings.
Thank you for helping me understand this RFC.
https://www.rfc-editor.org/rfc/rfc6749
As far as I know, your questions are not covered by the specs, so the answers below reflects only my personal opinion on a practical implementation.
A client may legally request several authorization codes with different scopes. You can argue if this makes sense (though I think it does), but the standard does not forbid it. Consequently, I think old codes should be revoked only if a client resends a request (i.e. with exactly the same request details: client id, redirect uri, scopes).
For missing redirect_uri, servers should return HTTP 400 Bad Request and include error details in the message body (and/or appropriate HTTP headers).
I'm currently working on an app that needs to integrate Vimeo. I'm therefore adapting my working OAuth2 client to allow authorization to Vimeo it's new beta API.
However, there are some things that are unclear to me, and the documentation is a bit vague on the matter.
Should I get the client authorized before authentication?
The user authentication url is https://api.vimeo.com/oauth/authorize, should I send a GET or POST request to this URL with the required parameters?
Should I send a basic authorization header (Authorization : basic base64(client_id:client_secret) along with authentication or should it be unauthenticated authorization header (Authorization : Bearer unauthenticated_access_token)?
Should I handle the authentication dialog through a UIWebView or through Safari?
Furthermore, I seem to get the error: { "error": "An unknown error has occured. Please let us know!"} when handling authentication through Safari. Does anyone have a clue on what actually went wrong or provide a way to find out? (Seems Vimeo improved their error displaying overnight ;))
The actual error I get is that the redirect_uri and client_id are missing, but I'm reasonably sure they get provided in the request body when doing a POST, or in the parameters when doing a GET. Any pointers?
Client authorization is not necessary to generate User authentication. Client authorization is only necessary to make unauthenticated api requests.
You don't make a request to api.vimeo.com/oauth/authorize, you send your user there. You should create a link, and put it on a page for your user to click. They will make a GET request to that endpoint, but it should not happen through your server.
Since your client is making a request to /oauth/authorize, there is no way you can define the headers. You will need to provide an authorization header to /oauth/access_token, and this should be Authorization : basic base64(client_id:client_secret)
We did fix a bug last night in our oauth error reporting :D. Sorry for the temporary confusion.
Without more information I can't really answer your error message. I'll add some comments, and then update this answer with more information.
When going through the Intuit technical review, Intuit has indicated that we need to check within our app to make sure the OAuth token is still valid.
So far I've found at least two different return codes that can happen when an OAuth token is invalid - are there more than just two? What other return codes should we be looking for?
Found so far:
HTTP 401 Unauthorized
HTTP 200 OK + a ErrorCode 3200
The only HTTP status that should be used is 401 Unauthorized. Any other response status is either a bug or a faulty implementation of the specification on Intuit's side.
It may be that the token is valid, just not for the resource that you are trying to access. In these cases it is good to be pragmatic and really specify for the API consumer WHY they get a 401. It is perhaps this scenario that Intuit covers with a 200 + error code. But this is just a guess.
Keith,
keep in mind you should not have to check to see if a token is invalid, you should always know. If the customer disconnects then they are sent to an OpenId endpoint with the realm where you can find them on your side and disconnect them.
Alternatively if you disconnect, then you know its invalid.
But yes this is a bug it should only be unauthorized. I just wanted to pointout that you should know the state before calling under normal use cases.
Jarred