I’m using implicit grant flow to authentication website users. I redirect them to auth0 using the following url:
GET my_domain.auth0.com/authorize?
response_type=token
&audience=my_api_id
&client_id=my_client_id
&redirect_uri=https://mywebsite.com/callback
&scope=openid profile my_custom_scope
&state=some_random_number
&nonce=some_number_number
I’m trying to include user information in the access_token. Yet, I never succeed! I have enabled “OIDC Conformant” in my client advanced settings. I have also added “openid” and “profile” to api scopes. I’m spending almost a day and all I see in all websites is to just add “openid profile” to the list of scopes and it should work. But, auth0 never returns any access_tokens with user information included.
“openid email” does not work either.
I can include them in “id_token” with just adding them to the list of scopes. But, that’s not what I want. I want them as part of “access_token”.
I can also add custom claims using rules:
function (user, context, callback) {
context.accessToken'https://name'] = user.name;
callback(null, user, context);
}
But, in this case, I must have an URI-formatted key. username is part of standard claims, I don’t want to use custom claims for something that is supposed to be standard!
Is there anything that I’m missing?
The scope parameter which was originally specified as part of OAuth2 provides a way for client applications to state the desired actions that they want to perform against the API to which the authorization request refers to. This set of actions would be reflected, either directly or indirectly, in the issued access token when following OAuth2.
The same scope parameter was then used/extended by OpenID Connect (OIDC) as a way for client applications to state that they are performing an (OIDC) request and that they are also interested in having certain user information - like the email
- included in the ID token issued as part of the request.
The request you’re performing against the .auth0.com/authorize
endpoint in your situation is both a request for API authorization (OAuth2) and a request that falls under the rules of OIDC. However, you still have to consider that including OIDC standard claims as part of the scope parameter will only lead to the automatic inclusion of that information in the ID Token; because that’s what the specification points to.
Additionally, neither the OAuth2 or OIDC specifications impose any format on access tokens; OIDC clearly states that the ID Token is a JWT and also goes on in declaring the standard claims that are used within it, but access tokens are left as an implementation detail of the authorization server. At this time when you use the API authorization feature, we do issue a JWT access token, but it’s not a JWT that follows the same rules of the OIDC ID Token.
In conclusion, if you want to include additional information into the issued access token you’ll need to use namespaced claims.
2 Likes
@jmangelo, so, I got the concept wrong! Thanks for helping me understand it. Appreciate it
1 Like