CODEWITHSUNDEEP
permissionsjwt
waqar
waqar

Reputation: 43

what is best practice to store user permissions in JWT token?

Our system architecture is like an admin can assign permissions on the user level. we are using JWT token for authorization, previously we use roles, and roles are added in payload on sever side we check that role and allow/disallow accordingly without hitting the database. But when we add permissions in the JWT token its payload is too heavy and affects the network traffic. So my question is what is the best practice to deal with user base permissions in JWT token.

Upvotes: 4

Views: 7828

Answers (2)

perustaja
perustaja

Reputation: 191

You really have two options if you are using JWTs and not some sort of session-based old framework.

  1. You store permissions in the JWT. As pointed out there are 2 main issues with this. Firstly it becomes stale, possibly quickly. Secondly this potentially bloats the JWT depending on how many permissions you have in your application. Also, for multitenant applications you now make it significantly more awkward to switch between tenants on the fly. Because now you need to reissue a token (somehow force a logout/login) whenever the user changes tenants.

  2. You handle permissions through a network call to a server (probably the login server) which remotely handles authorization. This adds overhead but keeps things responsive. The only downside is really network traffic. It may sound like there's ways around this but there really isn't and people have accepted the large amount of added traffic.

IMO do what is the least you need. There are bandaids for JWT staleness such as short refresh timers. There are also ways to work with bloated JWTs such as strings created from enum flags. If you do not need immediate refreshing of permissions or lots of them there is nothing wrong from a practicality standpoint of putting authorization data in the JWT.

If the above does not apply, then you need to setup a network call system to handle the authorization. Ideally this is faster/leaner than http network calls.

As an example I use gRPC calls. Example working repository you can see/run is at https://github.com/Perustaja/PermissionServerDemo

Upvotes: 1

Tedpac
Tedpac

Reputation: 1157

I don't think there is a "best practice" for this as it doesn't sound advisable to store a user's permissions in a JWT, because of the following:

Since a JWT must contain all the information necessary to execute a request, if at any given time a user has permissions removed, he will continue to have them for a period of time as long as his JWT has not expired. That is, using the approach you describe, adding or removing permissions from a user is not an effect that occurs immediately, so it is necessary to develop mechanisms so that the effect of those changes is immediate. Additionally, I consider that a user's permissions can be classified as sensitive information, and it is not recommended to store sensitive information in a JWT (since anyone can see it).

If you want to continue doing that, you can assign identifiers to permissions (such as small numbers) and store those identifiers and permissions in your server's RAM (for example, using a dictionary or hash table). Finally, in the JWT you only have to store the identifiers of the permissions, thus saving as much space as possible. This way there is no need to hit the database.

Upvotes: 4

Related Questions