Unable to add namespaced claims to ID Token while using /delegation with a refresh token flow

Help
,
1

It seems I’m not able to add additional custom claims to the ID Token for /delegation endpoint with a refresh token.

I have a rule which adds custom claims to both the access token and ID token. From the webtask log I can see that the rule is being run when I send the following request:

POST https://mycompany.au.auth0.com/delegation

{
  "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
  "client_id": "[the client id]",
  "refresh_token": "[refresh token]",
  "scope": "openid",
  "api_type": "app"
}

and the result I got

{
"token_type": "Bearer",
"expires_in": 36000,
"id_token": "[some id token]"
}

However when I decode the ID token, none of my custom claims are present, even though I’ve put them in the context.idToken object. This is according to https://auth0.com/docs/rules/context (actually there’s a discrepancy - it says to use id_token which I think is wrong. Regardless idToken nor id_token worked)

For example in my rule I’m setting:

// context.idToken already initialized  to empty object {} if it doesn't exist
context.idToken"https://api.mycompany.com/username"] = user.username;

Is this intentional or did I miss something? The custom claims seems to be correctly populated in id token when using grant_type=code.

2

The use of custom namespaced claims was introduced as part of the OIDC compliance mode (which is also in effect if you use any API Authorization related functionality) so this means that some endpoints that predate the final OIDC specification follow different rules and don’t have support for namespaced claims.

You mention that you have a rule that adds custom claims to access tokens and ID tokens. Given access tokens are opaque values except when issued as part of an API Authorization request for your own API this makes me assume you’re relying on the API Authorization feature set so you should not be using the /delegation endpoint for refresh token purposes (the delegation endpoint can currently still be used to obtain third-party API tokens).

The refresh token obtained as part of the authorization code grant (when in OIDC mode or as part of API authorization for an API that allows offline access) can be used at /oauth/token endpoint to execute a refresh token grant that follows the OIDC rules and as such should return your namespaced claims in the respective tokens.

If you’re starting your implementation and want to make use of OIDC compliance you can force your client application into OIDC mode through the client application advanced OAuth settings, more specifically, the OIDC Conformant toggle. Enabling this has breaking changes like disabling /oauth/ro and other legacy endpoints so if this is an existing application you may want to only do this after testing its effects in a development/staging environment.

For additional reference information check:

3

In relation to the docs page, you’re correct; there’s a typo on the page, as the properties within the context object are named idToken and accessToken. This should be fixed soon.

4

I see. Thanks for the info!

Some suggestion on documentation:

  • update the docs on old refresh token with this info
  • update the API docs with info on how to use the refresh token (there’s nothing there atm)
  • Fix Context Object Properties in Rules. To add custom claims it should be idToken not id_token (similarly, accessToken not access_token)