1. Introduction
The original OAuth 2.0 Authorization Framework [RFC6749] specification does not mandate any specific format for access tokens. While that remains perfectly appropriate for many important scenarios, in-market use has shown that many commercial OAuth 2.0 implementations elected to issue access tokens using a format that can be parsed and validated by resource servers directly, without further authorization server involvement. The approach is particularly common in topologies where the authorization server and resource server are not co-located, are not run by the same entity, or are otherwise separated by some boundary. At the time of writing, many commercial implementations leverage the JSON Web Token (JWT) [RFC7519] format.
Many vendor-specific JWT access tokens share the same functional layout, using JWT claims to convey the information needed to support a common set of use cases: token validation, transporting authorization information in the form of scopes and entitlements, carrying identity information about the subject, and so on. The differences are mostly confined to the claim names and syntax used to represent the same entities, suggesting that interoperability could be easily achieved by standardizing a common set of claims and validation rules.
The assumption that access tokens are associated with specific information doesn't appear only in commercial implementations. Various specifications in the OAuth 2.0 family (such as resource indicators [RFC8707], OAuth 2.0 bearer token usage [RFC6750], and others) postulate the presence of scoping mechanisms, such as an audience, in access tokens. The family of specifications associated with introspection also indirectly suggests a fundamental set of information that access tokens are expected to carry or at least be associated with.
This specification aims to provide a standardized and interoperable profile as an alternative to the proprietary JWT access token layouts going forward. Besides defining a common set of mandatory and optional claims, the profile provides clear indications on how authorization request parameters determine the content of the issued JWT access token, how an authorization server can publish metadata relevant to the JWT access tokens it issues, and how a resource server should validate incoming JWT access tokens.
Finally, this specification provides security and privacy considerations meant to prevent common mistakes and anti-patterns that are likely to occur in naive use of the JWT format to represent access tokens.
Please note: Although both this document and [RFC7523] use JSON Web Tokens in the context of the OAuth2 framework, the two specifications differ in both intent and mechanics. Whereas [RFC7523] defines how a JWT Bearer Token can be used to request an access token, this document describes how to encode access tokens in JWT format.
1.1. Requirements Notation and Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
1.2. Terminology
JWT access token: An OAuth 2.0 access token encoded in JWT format and complying with the requirements described in this specification.
This specification uses the terms "access token", "refresh token", "authorization server", "resource server", "authorization endpoint", "authorization request", "authorization response", "token endpoint", "grant type", "access token request", "access token response", and "client" defined by The OAuth 2.0 Authorization Framework [RFC6749].