12

Should information about the permissions and roles of the client be included in JWT?

Having such information in JWT token will be very helpful as everytime a valid token comes, it would be easier to extract the information about the permission about the user and there will be no need to call the database for the same. But does including such information and not double checking the same in the database will be a security issue?

Or,

Information like the one mentioned above should not be a part of JWT ever, and only the database should be used for checking the access roles and permissions of a user?

Anshul Sahni
  • 365
  • 2
  • 4
  • 12

3 Answers3

10

The purpose of including claims in the token is so you don't have to have that communication between the resource and the authentication provider.

The resource can just check that the token has a valid signature and trust the content.

Assuming the private key is private to the auth server you are good. Some providers change their key around to mitigate the risk.

If you think about it, if the resource made a call back to the auth server to get the claims. Then it is essentially ensuring that its talking to the right server by similar trust methods.

Ewan
  • 70,664
  • 5
  • 76
  • 161
  • Well thanks for a beautiful answer, may I know more about what you meant from your statement "Some providers change their key around to mitigate the risk." ? – Anshul Sahni Jun 25 '18 at 09:21
  • 1
    So rather than having a fixed signing key, the auth provider will change it every so often and provide an endpoint for resource servers to download the public half of it. The resources have to make calls to the auth server every so often, but not once per request – Ewan Jun 25 '18 at 10:09
  • So all the tokens are invalid everytime the key signature is changed by the service – Anshul Sahni Jun 25 '18 at 10:17
  • 1
    usually they will have more than one possible key, so that in flight tokens wont be invalidated. the token will contain a 'key id' to tell the resource which one to use – Ewan Jun 25 '18 at 10:18
  • The only thing I miss here is how to proceed when the data in the JWT is invalidated. Say the roles changed on the server-side but the client still holds the token with the all set of roles. You have to be able to revoke tokens on the server-side so those tokens holding outdated info are no longer valid and usable for further requests. This is in line with what Ewans is somehow suggesting (allowing the server to revoke token) for one or another reason. – Laiv Jul 19 '19 at 12:25
  • 1
    @laiv i think in that situation the expectation is that the client is instructed to "log off and on again" although they would pick it up on the next refresh – Ewan Jul 19 '19 at 13:48
  • By **resource** , I guess you mean resource server :) , I think authentication server can also ensure that all the tokens signed by one key will expire before the same key is removed. For example, an auth server maintains a key set, each key can be stored along with the time it was created, and each key has 2 states : e.g. `can_sign_n_verify`, `verify_only` , when auth server rotates the key set at regular interval , it determines whether to change state of each key or delete the key by comparing the create time with current time. – Ham Sep 29 '21 at 07:45
  • Wrong. There is so much missleading information on this topic. Implementing modern auth gets the identity token from an idp that has no clue about how authorization is done at the target system. – Tom el Safadi Apr 22 '23 at 01:20
2

From my experience, if all your systems are using some central role and permission database, you can add all that into JWT.

However, this approach might not work well in SSO scenarios when the auth server itself has no idea whatsoever about the target system that will receive and trust the token.

The roles and permissions of the user are entirely upon the receiver of the JWT token. It's especially true when you integrate SSO auth with JWT into some legacy systems that have already their permission subsystem in place and thus they need only one claim to be present in JWT - the claim of user identity.

JustAMartin
  • 159
  • 6
  • I agree on this. User permissions should not be a part of jwt specially in SSO since the idp isn’t aware of what other services this user jwt is going to talk to.. instead the resource should implement the authorization part once the identity has been confirmed for the user – Manish Rawat Mar 06 '20 at 01:37
  • I also agree that permission claims in JWTs are not a good idea beyond a simple monolithic API. I wrote a blog post about it: https://sdoxsee.github.io/blog/2020/01/06/stop-overloading-jwts-with-permission-claims – sdoxsee Mar 10 '20 at 14:25
2

One of the biggest problems I've come across is the fact that header size can become prohibitively large if you include all the user's roles/permissions.

Laredo Tirnanic
  • 31
  • 1