Leakage of Personal Information via JWT Access Token
Self-contained access tokens, typically JWT access tokens, contain associated data in themselves. If the following conditions meet, as a logical consequence, personal information leaks directly from such access tokens.
- Personal information is contained
- Stolen by unintended parties
“Stateless” here means that an access token does not have any corresponding database record on the authorization server side in which the access token can store associated personal information in order to avoid embedding the information in the access token itself.
If the implementation of access tokens is “self-contained, nonencrypted and stateless”, and if the system needs to provide personal information to client applications, the system should provide a Web API whereby to query about personal information and should avoid embedding the information in an access token itself.
The UserInfo Endpoint (OIDC Core Section 5.3) is such API, but keep in mind that a self-contained stateless access token needs to contain information about “what claims (user attributes) are requested at the UserInfo Endpoint” if the authorization server wants to support the
claims request parameter (OIDC Core Section 5.5) and that for some claims (e.g. ones related to medical records), existence of claim names itself can be privacy information.
Another relatively new concern is
authorization_details in an access token.
“OAuth 2.0 Rich Authorization Requests” (RAR) defines
authorization_details parameter. The parameter can be used at various places such as in authorization requests, token responses, introspection responses and JWT access tokens (Section 9.1).
However, the content of
authorization_details is too detailed to be embedded in nonencrypted JWT access tokens. Below is an example of the payload of a JWT access token from the RAR specification. The
authorization_details in the example contains detailed information about a purchase history record.
From a privacy point of view, handle-type access tokens are much better than self-contained access tokens. However, your system may have to use self-contained access tokens for some reasons. In that case, it is highly recommended (a) encrypting access tokens and/or (b) avoiding embedding personal information in access tokens.
Note that encrypting access tokens is not so simple as you may imagine. Read “OAuth Access Token Implementation” if you are interested in further discussion.