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?

Improve this question

3 Answers 3

Reset to default
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.

Improve this answer
8
  • 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, 2018 at 9: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, 2018 at 10:09
  • So all the tokens are invalid everytime the key signature is changed by the service
    – Anshul Sahni
    Jun 25, 2018 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, 2018 at 10:18
  • 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, 2019 at 13:48
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.

Improve this answer
2
  • 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 6, 2020 at 1: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: sdoxsee.github.io/blog/2020/01/06/…
    – sdoxsee
    Mar 10, 2020 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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.