Boundaries of using Claims in the authorization JWT token OAuth2+OIDC

user_12885746 0
Viewed 167

The main our product is Public API. We use IdentityServer4 for the authentication and authorization of our users. Now I'm fighting with my teammates about the number and type of information that can be in claims in token. For instance, usually, we add the user identifier and the identifier of user's organization in claims. Also, we add user's configuration, such as

  • server URL where the user was provisioned
  • internal identifier of the user
  • user's device identifier These user's configuration properties are requested from different internal services and databases during authorization and generating JWT tokens.

There is an option - keep in JWT token only the user identifier and request all configuration properties in the API method. The main pros of keeping configuration in claims from my point of view are decreasing requests to other services and to the database.

Perhaps, there are best practices about my question from reliable sources or even in RFC what the information can be in claims?

claims-based-identity jwt oauth-2.0 openid-connect api
1 Answers

There are no RFCs or standards which would say what information can end up in claims and which don't. I would try to stick to those guidelines:

  1. Try to keep information in tokens as minimal as required. Don't put something in claims only because maybe one service will need it from time to time. Put only those claims which most of the service use all the time, or information which needs to be asserted by the Authorization Server. The other data usually belong to the microservices themselves or can be easily obtained through API calls. This is especially important if you're using JWTs publicly available on the Internet, as anyone can read those information.

  2. Try not to put Personally Identifiable Information in a JWT, especially if the token is available publicly. When someone steals such a token they will be able to read your users' PII. If you need this kind of information in a token, then think of using the Phantom Token pattern. This way the information is safe from eavesdroppers.

  3. By limiting the amount of claims in a token you can also limit the permissions of a token. It's better to have tokens with lower permissions and use token exchange whenever more information or privilege is needed.

  4. Remember that the claims in the token are a contract between the Authorization Server and the consumer (usually the API). Once you add something to a token, you usually won't be able to remove it, as this will constitute a breaking change.

Have a look at these articles we wrote at Curity to get some more knowledge about dealing with claims and JWTs:

user_17122940
Related