✓ assign users to it - both tasks very easy so far, thanks to the Users & Roles Dashboard
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:
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?
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.
As the feature says,
“Add Permissions in the Access Token”
As for why the AT is opaque, please see the linked doc above.
after a user with the “Admin” role logs in, store their role in the JTW
