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.
Related
I'm stuck with an issue while trying to use Google's OAuth2 php lib. On the server side, after I instantiate an OAuth2 object I redirect the user to Google's sign in page, after which they hopefully grant permissions based on the scopes (the APIs I declared for use in the OAuth2) I declared. Now here's my issue: after the user grants permission I get redirected to the redirectUri I specified during the instantiation of OAuth2. This redirectUri contains as params state, code, and scope k-v pairs. I always get a "Missing authorization code" if I don't send back the value code to server and set it as a property of the OAuth2 object. However, if I send back the value of code to the server and set it as a property of the OAuth2 object I get a
"Client error: POST https://www.googleapis.com/oauth2/v4/token
resulted in a 400 bad request response. Error: "invalid_grant"`
So, I'm at lost here. I should mention that I actually managed to make 2 authorized calls to Google Ad Manager (the scope I declared) using the same flow I described above, but after that I keep getting the same 2 errors as above.
Does anybody know what's going on? I must be missing something but I can't see what. I'm using this guide so it's not really convoluted or complicated code but I just can't get it to work somehow. https://github.com/googleads/googleads-php-lib/wiki/API-access-on-behalf-of-your-clients-(web-flow)
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.
We're trying to move from the older WindowsLive API to the new Microsoft Graph API. In the process, we're running into difficulty with the required OAuth 2.0 redirect_uri parameter in the app.
According to the Oauth 2.0 RFC, the redirect_uri must be an absolute path but can contain a properly encoded query string.
In our Windows app, we've setup the absolute path - their application tool doesn't allow query strings to be added: https://example.com/index.php
The OAuth request we make uses a redirect_uri with URL Encoding, including query params. This is necessary, we use a CMS (Joomla) that needs to know what should handle the request:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
response_type=code&
client_id={string}&
redirect_uri=https%3A%2F%2Fexample.com%2Findex.php%3Foption%3Dcom_jfbconnect%26task%3Dauthenticate.callback%26provider%3Dwindowslive&
scope=user.read&
state={string}&
access_type=offline&
approval_prompt=auto
However, the Graph API rejects this with:
"The reply url specified in the request does not match the reply urls configured for the application"
Anyone else run into this or understand why the Graph API doesn't accept query parameters either in the app configuration or on the token requests?
Edit - 5/8 - However, the application setup area does not allow query strings in the redirect_uri setting, which is correct according to the RFC. However, the Graph API isn't respecting this note of the RFC:
The endpoint URI MAY include an "application/x-www-form-urlencoded" formatted (per Appendix B) query component ([RFC3986] Section 3.4), which MUST be retained when adding additional query parameters.
This isn't actually being rejected by Microsoft Graph. Microsoft Graph is simply an API and it doesn't generate or manage access tokens. That process is handled by Azure Active Directory.
The error you're getting is due to your redirect_uri not being configured in your app registration at https://apps.dev.microsoft.com. The URL must explicitly match the URL configured in the registration. From the documentation:
The redirect_uri of your app, where authentication responses can be sent and received by your app. It must exactly match one of the redirect URIs you registered in the portal, except it must be url encoded.
For scenarios where you need to pass data through, you should encode those values in your state parameter. This will be returned to your redirect URI along with the authorization code.
Also note that neither access_type=offline or approval_prompt=auto are valid query parameters:
To retrieve a refresh_token, you add offline to your list of scopes (user.read+offline).
To set the type of prompt the user receives you use the prompt parameter. Valid options are login, none, and consent.
As part of the OpenID Connect (OAuth2 for Login), my application is supposed to request an access token, given a one-time authorization code, via the endpoint https://www.googleapis.com/oauth2/v3/token. According to documentation, this request needs 5 parameters passed to it, client_id among them. That is exactly what my application does, using the Perl module Net::OAuth2.
Everything has been working fine for several months, but today I was notified that it stopped working. No updates were made to the application code nor the libraries used by it.
The message my application now receives from the server when calling the token endpoint is this, in a 400 error response:
OAuth 2 parameters can only have a single value: client_id
A Google search suggests nobody has ever seen this message before, or lived to tell the tale. There doesn't seem to be a general issue with Google's OpenID Connect (other services based on it are working flawlessly), and the imminent shutdown of the old login protocol doesn't seem relevant.
More testing: removing all parameters except client_id causes this error message:
Required parameter is missing: grant_type
Supplying only client_id and grant_type produces the original error message again.
Does anyone have an idea what's going on here?
Google changed this behavior few days ago, so any OAuth2 library using Basic Auth headers AND body request parameters will start to see messages like
OAuth 2 parameters can only have a single value: client_id
or
OAuth 2 parameters can only have a single value: client_secret
So, you must now do NOT use both (the Auth headers and body request parameters) at the same time to send credentials to Google.
And according RFC 6749, the preferable way to send credentials is through Auth headers (thanks #JanKrüger for alert me about this).
Got the same error. It seems the problem is that NET::OAuth2 sets the authorization header when exchanging authorization code for access token. If you remove this header everything works fine.
Check the get_access_token method in Net::OAuth2::Profile::WebServer module. The authorization header includes client_id:client_secret base64-encoded string. Apparently Google now treats this duplication as an error.
The right way of fixing this is to set the secrets_in_params parameter when creating Net::OAuth2::Profile::WebServer object. Look in the Net::OAuth2::Profile documentation for more details.
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).