How to store/design dynamic roles in jwt
I've been working on a project that has users that can join groups that are either public or private. I'm using refresh und jwt access tokens for authentication of the api. For most examples online, roles are always defined statically like this user is has an admin or user role.
To reduce database fetches to check if a user can see contents in a group (so either is a user a member or is the group public) for every request, is it reasonable to save roles on a group bases in the jwt token?
The problem I see is that a high number of groups can be public and therefore a lot (to many) of roles have to be added.
Or is this approach of dynamic roles (not sure how to call it, what I mean is creating roles depending on a group) just completely wrong in itself?
Maybe someone can give an example how such complicated content access is checked in the real world 🙂
9 Replies
Is there resource access on these groups or are they just convenient containers for global permissions?
Also, does the service have access to the auth data?
If you can get away with a bunch of questions with a finite number of answers, I would just take all the user's "groups" with their permissions converted to a binary number and bitwise or (|, not ||) them together and have one field named "permissions" in my JWT. In this case, you don't care where the permission came from, you just care that the user has the permission to do X. The advantages to this are that it is small and fast, the disadvantages to this over keeping a list is that you are limited by space (if you are using a sane language with fixed width integers) or you are somehow going to have to finagle a list of multiple integers. It is also less legible.
If there is resource access contingent upon the group you are in (think a file system), you either will perform a lookup on the database on every request or you will have to retain a list of group ids and any associated permissions. There is no way around this, but you are going to have to do a database lookup anyways for the resource. I would pack the group permissions the same way though as it will keep the group relatively small. I would probably do this in a dictionary/associative array/hashmap/whatever the data structure is called in your language of choice on the back end so it looks something like this:
Don't store access permissions in a jwt
Always check the database for them
That would be my preference too.
If youre going to use sensitive data, like permissions, in a jwt, wouldnt it be better if you encrypted it , to keep it stateless? JWE works great in ym experience implementing it myself.
Encryption can always be decrypted so it not totally secure
Roles or multiple roles should be in the database
Agree with that. If some data can change you shouldn't store them in JWT. Id is most important. You can store Id in JWT and then with this check user permissions with database
i personally try to store as little information in a JWT as possible. Let your server do all the work. While JWTs are secure, I dont want to trust any information from the client that I dont have to. Plus, what happens if you need to refactor code and in the refactor you end up changing flags or permission levels? I usually just have an id in the JWT and not a lot else.
Yea that's how if have done it up until now because but I didn't know why. Makes definitely sense for security reasons as the tokens decryption would give away private information on group membership
Tho I see the point in changing permission levels, I would just encode the roles in the access token when created. The access token would only have a short lifetime or be invalid in server restart. Which would be the case for me on updating the code. But I do see the point for bigger systems where the possibility for servers running different versions is possible
Thanks guys, helped a lot
Anytime