This simple rule seems to be executing upon user login, but I’m not able to see the custom claim in the user’s access token obtained from POST /oauth/token. Is there something I’m missing?
function (user, context, callback) {
context.accessToken['http://example.com/email'] = 'test@example.com';
console.log('Appears in logger extension upon login', context);
callback(null, user, context);
}
Your code looks like it is adding the custom claim correctly. I tested out the rule in my own tenant, and after logging in, the decoded JWT Access Token looks like this:
Ah, okay! When you make the POST /oauth/token request, you should receive two tokens, an ID Token and an Access Token. The ID Token is used for your frontend to get basic profile info about the user. The Access Token is for your frontend to send to your API as a bearer token. The token you have shared looks like an ID Token.
If you’d like to add a custom claim to the ID Token, you’d adjust the rule like so:
function (user, context, callback) {
context.idToken['http://example.com/email'] = 'test@example.com';
console.log('Appears in logger extension upon login', context);
callback(null, user, context);
}
To get the Access Token instead of the ID Token, you can use the getAccessTokenSilently hook:
Hmm, very interesting. It looks like the values I’m getting for access_token and id_token might be swapped. Here’s what the response looks like for POST /oauth/token.
access_token is a short token and id_token is the JWT that I posted decoded above.
It sounds like your app may be receiving an opaque token. An opaque token is returned when an audience is not specified in the Auth0Provider. The audience should be your API’s identifier: