Easy way to put user role in JWT

What I’m trying to do:

  1. ✓ define an “Admin” role for users, and
  2. ✓ assign users to it - both tasks very easy so far, thanks to the Users & Roles Dashboard
  3. :question: after a user with the “Admin” role logs in, store their role in the JTW

This is such a common request that there are numerous threads about it (1, 2, 3, etc.).

I’m coming from Firebase Auth, where this is exceedingly simple. While Firebase Auth doesn’t have the ability to assign users to roles through its dashboard, it’s very simple to assign any claims via its management API:

firebase.auth().setCustomUserClaims(uidOfTheAdminUser, { admin: true })

That’s it, one line of code. If some OIDC-compliant namespacing is necessary, that’s still one line.

How do I do this in Auth0? I’m reading about custom claims, then the example mentions a “favorite_color”, which IMO is a far less common example than a role. Then I must learn about rules, then figure out how to map between roles and rules (the Custom Claims page says nothing about Auth0 roles), then possibly other concepts. Rules are functions, which may partially defeat the purpose of having a Dashboard that non-technical staff can work with.

I’m trying to achieve what I think is one of the most common and basic authorization tasks: convey to our API server whether the logged in user is an Admin or not. Is there an easy and succinctly explained way to do this?

Hi @Civility,

Check out this example:

It adds the role to both the id and access tokens, you may want one or the other or both.

Namespacing is enforced, as it makes custom claims collision resistant.

Let me know if I can help any further here.


That rule worked, thanks!

Though on the Sample Use Cases page above, I’m not sure if “If you enable RBAC for APIs and set the Token Dialect appropriately …” counts as “easy” (what’s the “Token Dialect”? it’s not linked; is it necessary to learn yet another concept? How does Firebase Auth manage to not require this?).

Anyway, while enabling RBAC for our API, I noticed this:

That sounded like enough for what we need, doesn’t require a rule, and would be easy enough for non-technical staff. I’ve enabled “Add Permissions in the Access Token”, added an “admin” permission to our API, added that “admin” permission to our “Admin” role, logged out from our web app, logged back in, and decoded the received idToken. But - it did not contain any permissions field. Any idea why? (the accessToken was something like xFgQCQFCGLbqM-MAvjBO4HTFoPsHTEDU, not a JWT).

BTW, I submitted a PR to clarify where the Token Dialect comes into play and what (I think) “appropriately” means, i.e. the access_token_authz dialect, which allows a permissions field. I suppose setting the “Add Permissions in the Access Token” toggle in the screenshot has the same effect as the toggle in the screenshot? There was no permissions field anywhere, while I was logged in as an Admin user, for which the “Add user roles to tokens” rule did add the correct role.

I think what the token dialect refers to is whether or not the token is an opaque token or a JWT. I agree, that is confusing. Token dialect is not something I have seen referred to often.

At this point, I am fully aware of your preference for firebase. :wink:

As the feature says,

“Add Permissions in the Access Token

As for why the AT is opaque, please see the linked doc above.

Thanks for taking the time to do that!

So were the permissions encoded in xFgQCQFCGLbqM-MAvjBO4HTFoPsHTEDU? How can they be decoded?

You need to add an audience. Take a look at this FAQ.

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.