Add custom scopes in the access token ( Authorization code flow with OIDC provider)

Dear Community

I am creating a simple spring based application using Auth0. The application is based on Spring security and web dependencies. I am able to register the application on Auth0 and using the Universal login with google as IDP provider able to authentication. The question i have i need to have custom scopes added to the access token . Please guide me on this aspect of modifying access token ( i have checked hooks but it is applicable for client credential flow ) . It will be great if you could point me to relevant documentation or steps for enriching the access token with custom scopes using spring security and auth0.


Hello @arokde - welcome to the Auth0 Community!

The documentation you’re looking for is here: Sample Use Cases: Scopes and Claims

In the example, they mention context.idToken, but context.accessToken is also available, so you can enrich any of them.

Let me know if this helps!

Hi @joseantonio.rey

Thanks for the quick response. Quick answer the documentation link you specified i followed it but does not address the problem.

Here is snippet of rule which i have coded

function (user, context, callback) {
  // TODO: implement your rule
  //  access_token.scope = scope;
  context.idToken["http://mynamespace/roles"] = ['guest'];
  context.idToken.scopes = ['guest'];
  return callback(null, user, context);

May be i am missing something . In addition here is what i am trying to do

  1. I have created API ( APITest) where in i have added custom scopes ( permissions ) to it

  2. I have created Web Application (WebTest) which has been given permission to the above API and i am invoking this application using Spring boot and security. ( Authorization Code Grant Flow)
    3.In the application i have following snippet which is invoked when the authentication is successful

    private ClientRegistrationRepository clientRegistrationRepository;

     private OAuth2AuthorizedClientRepository oAuth2AuthorizedClientRepository;
     public String home(Model model, @AuthenticationPrincipal OidcUser principal, HttpServletRequest request, HttpServletResponse response) throws UnsupportedEncodingException {
         if (principal != null) {
             model.addAttribute("profile", principal.getClaims());
         return "index";
  3. What my expectation was that i would be able to access both token ( identitytoken and access token ) using the clientRegistrationRepository. Unfortunately i am able to get identity token but not the access token.

  4. When i invoke APITest application using the client credential flow , we are able to retrieve the access token.

I am sure i am missing something. As long as i am not able to retrieve the access token , any modification to it in the form of rules does not make sense.

Any help in this direction would be appreciable.


Just to add also experienced the same issue highlighted here

Scopes vs Permissions confusion where in the scopes added into the api are added in permissions and not in the scopes attribute

“iss”: “”,
“sub”: “google-oauth2|109487646265427827841”,
“aud”: [
“iat”: 1599543150,
“exp”: 1599629550,
“azp”: “2LnQOpLSecBbDM3sEGGt5QaSvEGwwep6”,
“scope”: “openid profile email”,
“permissions”: [

Hello, @arokde,

Once the token has been generated, you should not be tampering with the scopes. You can add metadata, but tampering with the scopes takes away all the security benefits of this specific part of the flow.

On the other hand, you list accessTokem when the correct object is accessToken, and you are not namespacing your claims. Make sure that you follow the document step by step in order to achieve the intended results.

I did realized the typo about it and rectified it but seems to not to solve the issue. I do agree with you about not modifying the token once it has been generated and i do not intend do it in my final application. I went through this approach as the permission/scopes defined in the api where not being made available in the access token if i use the Authorization Code Grant flow. This seems to work perfectly well for Client Credential. I have set the audience attribute in the helper utility provided by Auth0 but still not luck.

Hope this provides you more data in helping you out.Sorry being persistent but need this solved quickly so as to make further decisions.


Hey @arokde,

Then that’s a different issue :slight_smile: Are you explicitly requesting the scopes, as listed in our documentation? Scopes

Just as you pass on the audience, you have to pass on the scope parameter, listing all of the scopes you want for that specific audience. These are not assumed because different parts of your application might require different scopes, and we have no way of knowing.

Give it a try and let me know if it works for you.

I have added a permission to my API under the permissions tab (XXXX:test) an in my actual api (in AWS) I have provided XXXX:test as a scope to the JWT verifier. Adding XXXX:test to my machine to machine client works well, tho when ever a user signs up (or logs in) the
a) user consent never shows XXXX:test
b) the returned scopes in the access token never have XXXX:test

following all the steps in Sample Use Cases: Scopes and Claims never add the custom scope to my access token

I don’t really want to resort to hard coding a scope in a rule (I was not successful anyway) tho I can not for the life if me get the scope into my access token. Any pointers will be helpfull

Here is a request to auth0 pkce flow we are making

AuthorizationRequest {crypto: NodeCrypto, usePkce: true, clientId: “CCCC”, redirectUri: “”, scope: “openid offline_access profile email XXXX:test”, …}
crypto:NodeCrypto {}
extras:{prompt: “consent”, access_type: “offline”, audience: “”, code_challenge: “-Dmmmm”, code_challenge_method: “S256”}
internal:{code_verifier: “someVerfiyer”}
scope:“openid offline_access profile email XXXX:test”

also, I attempted to use the example provided
and got a 404
so now I am really confused

1 Like

I have the exact same issue as @josephsk . It would be nice if we could get some feedback on this. It’s setup and working correctly for M2M, but not in client app flows.

Well, I figured it out.

After reading API Scopes

I got the idea to start flipping the RBAC switches in the API’s settings. Ours were toggled on to begin with, after toggling them off the custom scopes come through just fine. We’re not using role-based permissions in the Auth0 layer so our use-case is safe to just disable. If you’re using roles I suppose you’ll have to set those up to play well with custom scopes.