9

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?

7

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.

  • 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 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 '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 at 12:25
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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