Scope not working for newer Clients/Lock (OIDC Conformant)?

Help
, ,
1

If I pass in the following scope :

oidcConformant: true,
    allowedConnections: 'Username-Password-Authentication'],
    auth: {
      redirectUrl: myConfig.callbackURL + 'pages/dashboard',
      responseType: 'token id_token',      
      audience: `https://${myConfig.domain}/userinfo`,      
      params: {
        scope: 'openid name email picture roles'
      }
    },

I am only getting this :

{"sub":"auth0|587a426c797fd715d804blabla","email":"blabla@gmail.com","emailVerified":true}

With the getProfile method I used to get everything I need based on the idToken. Now with the getUserProfile and based on the accesToken I am not able to retrieve everything.

If I pass in the profile scope which is not recommended. I am getting almost everything except a crucial part.
ROLES AND GROUPS they are missing.

{"sub":"auth0|587a426c797fd715d8040f27","name":"blabla@gmail.com","nickname":"apixxx","picture":"https://s.gravatar.com/avatar/10bc62166892f53bd05bcb2df4f2c424?s=480&r=pg&d=https%3A%2F%2Fcdn.auth0.com%2Favatars%2Fap.png","updatedAt":"2017-01-19T18:18:44.752Z"}

How to get the roles and groups now from the Auth0 Authorization Extension?!!

2

With OIDC conforment clients, the way to add scope in rules have changed slightly; we now allow the user to define scopes in the API & OpenID, and custom claims are now name spaced. Therefore, you’ll need to pass this information to your token via another rule. There are 3 scenarios are as follows.

Using ACL based on permissions stored in scopes.

In this approach there are granular permissions defined for example consider the following permissions create:user, update:user, create:task, update:task, update:current_user, create:current_user_task, update:current_user_task. An admin user will have access to all these scopes however a normal user will have
access to only :current_. You can add this in scopes as follows

    const rolePermissionsMap = {
        'admin': 'create:user', 'update:user', 'create:task', 'update:task', 'update:current_user', 'create:current_user_task', 'update:current_user_task'],
        'commoner': 'update:current_user', 'create:current_user_task', 'update:current_user_task'],
    };

// This accounts for multiple Roles.
user.roles.forEach((role) => {
    if(context.idToken){
        context.idToken.scopes = context.idToken.scopes.concat(rolePermissionsMap[role]);
    }

    if(context.accessToken){
        context.accessToken.scopes = context.accessToken.scopes.concat(rolePermissionsMap[role]);
    }
});

Using a custom claim.

Using a custom claim, you can define it as follows

const namespace = context.request.query.audience;

if (context.idToken) {
   context.idToken[audience + '/role'] = user.roles;
   context.idToken[audience + '/groups'] = user.groups;
}

For ID Token only

You can add the entire app_metadata/user_metadata object in the idToken by the following

context.idToken'app_metadata'] = user.app_metadata; // the same follows for user_metadata.

Please note that this will also apply to /userinfo, whatever you return as idToken will be served as /userinfo

Fetch it on the server

Finally you can fetch this information from either Management API (If you have persistence enabled in the Auth Extension) or Using the Extensions API.

3

This transition seems to be incredibly confusing.

It appears that a lot of basic use-cases have been broken and full support is still in development on the auth0 side though i can’t find good documentation on exactly what is still in development vs. what currently works. It’d be great at least, if all these workarounds could be migrated into a single living document somewhere instead of posted ad-hoc in the forums. Perhaps when the Auth0 folks respond to an issue like this, they put the answer in a single “Post-Migration Patterns” or somesuch page, and link their forum post to that?

1 Like
4

Testing hidden comment

5

Hello testing response