We have been using v2 of the Authorization extension to assign roles to users and return them in the id_token. Sometime within the past couple of weeks, the roles stopped being sent in the token, even though our code has not changed. I enabled debugging for the rule generated by the extension, and can see the roles logged in the user object. We are still sending scope = openid roles to the authorize endpoint, but it’s not returning the roles.
![alt text][1]
![alt text][2]
Update
The application is not configured to be OIDC compliant and there is no account-level default audience:
![alt text][3]
![alt text][4]
We are using version 2.0.3 of angular-lock, 8.9.1 of auth0.js, 10.20.0 of auth0-lock, and 2.4 of the authorization extension. We are displaying lock with lock.show() and passing in scope=“openid roles” and state=“/admin” in the params object. On the redirect back, we are decoding the id_token with jwtHelper.decodeToken() from the angular-jwt library. When we decode the token, this is what is in it:
![alt text][5]
We have not made any custom changes to the authorization extension, and have enabled passing the roles in the token contents:
![alt text][6]
The use of scope=openid roles will only be meaningful if the request is being performed in legacy mode. This is due to the fact that roles is not defined as part of OpenID Connect specification and as such in compliant mode it will not trigger any automatic inclusion of user data in the ID token.
The above means that I can reproduce the behavior by doing any of the following:
- configure the client application to be OIDC compliant by enabling the respective toggle in the client application advanced settings.
- configure a tenant level default audience in the account settings; the use of
audience parameter implies OIDC compliance so setting a default audience will have that side-effect for every request.
- providing an
audience parameter in a specific authentication request.
The information provided is sufficient to rule out the third option as you do not seem to be including an audience parameter, however, the other two situation could still explain the situation without implying any sort of bug as the omission of roles from the ID token would be the expected behavior in those situations.
Can you confirm that you in neither of the other two situations and if you’re not can you add more detailed information on how to reproduce this situation, for example, libraries being used, methods on those libraries and how you call them; version of the authorization extension, how you configured it and if you did any manual changes to the authorization rule.
Looks like it was a global issue. Resolved now
Could you be more specific about your “global issue”? I’m having the same problem and have all the same settings you do but cannot get the Roles to come back in the id_token.
If not, I understand and thanks in advance for your response.