OAuth 2.0 has become the standard authorization framework for securing APIs. At the heart of OAuth 2.0 are access tokens, credentials that allow an application to access protected resources on behalf of a user or itself.
Typically, access tokens indicate that the client app has been granted permissions to access specific resources, such as user data.
OAuth 2.0 itself doesn't specify a format for access tokens, leading many implementations to adopt proprietary token formats. RFC 9068 addresses this by defining a standardized JSON Web Token (JWT) profile for OAuth 2.0 access tokens, enabling better interoperability and security.
Originally, OAuth 2.0 tokens were opaque strings requiring additional calls to authorization servers for validation (token introspection). JWT access tokens eliminate this overhead by embedding structured token information directly into a cryptographically signed JWT, allowing resource servers to independently validate tokens.
For developers, RFC 9068 simplifies token validation by eliminating additional round trips to authorization servers for token introspection.
Consider an e-commerce mobile app that allows customers to view their profile information, manage orders, and check their purchase history. To access these protected resources, the app needs an access token issued by an authorization server after successful user authentication. This access token authorizes the app to interact securely with the e-commerce resource server at `https://api.ecommerce.com`.
JWT access tokens contain standardized claims within their payload. RFC 9068 specifies the following required claims:
iss (Issuer): URL identifying the authorization server.
sub (Subject): Identifier for the customer or client application.
aud (Audience): Identifies the intended resource server.
exp (Expiration): Indicates when the token becomes invalid.
iat (Issued At): Timestamp of token issuance.
jti (JWT ID): Unique identifier to prevent replay attacks.
client_id: Identifier of the OAuth client application.
Here's a sample JWT access token for our e-commerce app:
The mobile app explicitly requests JWT access tokens by including a resource
parameter and scopes within the authorization request. Here’s an example request:
The resulting JWT token issued upon successful authorization looks like this:
Header:
The e-commerce resource server validates JWT access tokens independently by:
iss
, aud
, exp
) match expected values.typ
) header explicitly states at+jwt
.Here's a simplified Node.js validation logic example for our e-commerce API:
RFC 9068 mandates specific practices to ensure security:
none
algorithm.aud
) for different resources to avoid cross-JWT confusion.As JWT tokens carry user information, the e-commerce authorization server must consider privacy implications:
sub
) identifiers per resource to prevent tracking across resource servers.This RFC can be avoided in highly sensitive environments requiring opaque tokens and frequent token introspection. It’s also best avoided if there is limited support for cryptographic operations.
RFC 9068 brings standardization to JWT access tokens, facilitating secure, efficient, and interoperable OAuth 2.0 implementations. This standardized profile reduces complexity and enhances security by clearly defining token structure, issuance, and validation processes.
By adopting RFC 9068, developers and organizations can ensure their OAuth 2.0 implementations are more secure.