I am trying to work out why I no longer see the user information in the id Token. I only see issuer and the metadata that the auth extension has added to the user.
I have set up a test app with an asp.net core backend API. I’ve followed your (Single-Page Applications (SPA) with API) guide - that I’ve tucked away behind an API I’ve setup and a couple of test permissions. When I examine the JWT, I see the scopes I’ve added but I no longer see username, nickname, email etc.
I’ve checked that I’ve registered scope as “openid profile email” and I’ve added a test scope “read:testdata”.
I’ve also added the country rule and I’m also seeing that information, but the user profile is eluding me.
TL;DR You may be looking in the wrong (JWT) token; ensure you’re checking the ID token and not the access token.
One thing to consider when you have a scenario involving an API treated as an independent entity (is represented in the API section of the dashboard) is that the authentication flow will then include an audience parameter targeting that API.
The use of audience in conjunction with a scope containing openid means that you’re making a request that is both an OpenID Connect one (you want to receive an ID token) and a regular OAuth 2.0 authorization request (you want to receive an access token valid to call the API).
From the above comes that you now have two token being issued:
the ID token which is always a JWT because the OIDC specification says so.
an access token which from a specification perspective may or may not be a JWT. However, from an implementation perspective, at the time I’m writing this, an access token issued by the Auth0 service for one of your own API’s will also be a JWT because there’s no other format from which you can choose from.
From this sentence:
When I examine the JWT, I see the scopes I’ve added but I no longer see username, nickname, email etc.
it makes me believe the issue is that you’re looking for profile and email information in the access token because at this time the Auth0 service does issue a JWT access token containing a scopes claim.
An ID token which is where you would expect to see profile and email information if you requested it using the scopes openid profile email won’t have a claim for the scopes.
Now, all of the above even if right is not immediately useful because the access token is indeed the token you should be sending to an API in this particular situation. There’s a few ways for an API to get additional information for a user after having received a valid access token, for example:
an access token will include a sub claim containing the user identifier so an API can query the Auth0 Management API directly as means to obtain additional data.
if the API is configured with RS256 the issued access token will have an additional audience associated with the /userinfo endpoint so the API could call the /userinfo endpoint with that access token and receive the equivalent information that would be present in the ID token.
you can explicitly include custom claims in the access token (OpenID Connect Scopes).