I should get a token with the above scope encoded into it, but the token has no scopes.
Note that when I run it in the editor, the return shows that the scope is added.
Because that wasn’t working, I tried creating a rule, but that’s not working either. It fires, but I don’t get an identity token when the rule is active.
function (user, context, callback) {
if (context.accessToken.scope === undefined) {
context.accessToken.scope = [];
}
context.accessToken.scope.push('added.scope.in.rule');
callback(null, user, context);
}
When I run this in the editor, I get a response that shows the scope is added to the accessToken property.
Hi Greg. Hooks don’t run when a user logs in (see here for the events to which you can associate a hook).
As for the rule, you are on the right track, that code should work. Are you checking the access_token or the id_token in the result? You mention that “you don’t get an identity token”, but the scopes apply to the Access Token instead.
Credentials Exchange: change the scopes and add custom claims to the tokens issued by the Auth0 API’s POST /oauth/token endpoint
I read this as, “I can use the hook to edit the scopes before the token is generated whenever someone asks for a token.” When someone logs in, they’re asking for a token, so I would expect this to fire.
I’ve updated my rule to use context.idToken instead, and while I now get an identity token, it doesn’t contain my scope.
The documentation on this is lacking. It says the context has an idToken property, but when I click on the ID Token link, I can’t see what’s available to edit in that field. How would I add a scope as a claim on the JWT that’s returned?
The docs for the hook refer to the Client Credentials Exchange, a flow where an app can directly request a token at the /oauth/token (a machine-to-machine flow) by providing its client id and client secret.In this flow, there’s no user interaction.
As for the missing scope claim in the ID Token: the scope is only available in the Access Token.
The OAuth 2, the Access Token represents a credential that can be used by an application to access a resource (an API). The “scope” claim represents the type or level of access granted for that token.
The ID Token, on the other hand, is a token meant to contain the identity of the user and information about the authentication process. Its target audience is the application itself and it doesn’t carry any scope because it’s not a token used to access a resource.
By default, the ID Token only carry claims defined in the OpenID Connect spec. You can add custom claims to it with additional information about the user, but these claims need to be namespaced (that’s why a scope claim without a namespace is rejected).
This doesn’t (because scope is treated as any other claim, and since is not part of the standard OIDC claims is rejected because it’s not namespaced):
context.idToken["scope"] = "something";
I will make a request to the docs team to improve the documentation on the context object to clarify that the context.idToken sub-properties are simply the claims contained in the ID Token (that need to be namespaced if they are not part of the OIDC specification).
To add custom claims to either the ID token or the access token, you need to use a namespace, which cannot come from the auth0.com domain. See my previous message (“This works:” / “This doesn’t”).
Okay. I see the difference. What are the requirements for what qualifies as a namespace? I see the examples above and in the linked “custom claims” page using a base url. Are there other options?
Any non-Auth0 HTTP or HTTPS URL can be used as a namespace identifier, and any number of namespaces can be used. The namespace URL does not have to point to an actual resource, it’s only used as an identifier and will not be called by Auth0. auth0.com , webtask.io and webtask.run are Auth0 domains and therefore cannot be used as a namespace identifier.
As this topic is related to Rules - Hooks - Actions and Rules & Hooks are being deprecated soon, I’m excited to let you know about our next Ask me Anything session in the Forum on Thursday, January 18 with the Rules, Hooks and Actions team on Rules & Hooks and why Actions matter! Submit your questions in the thread above and our esteemed product experts will provide written answers on January 18. Find out more about Rules & Hooks and why Actions matter! Can’t wait to see you there!