]> China Mobile

BeiJing China chenmeiling@chinamobile.com

China Mobile

BeiJing China suli@chinamobile.com

Security OAuth Working Group OAuth Roadmap Security Authorization RFC The OAuth 2.0 ecosystem has expanded significantly since the publication of RFC 6749, resulting in a complex landscape of extensions, security best practices (BCPs), and application-specific profiles. This complexity can be daunting for implementers, architects, and security auditors. This document serves as a comprehensive roadmap to navigate this landscape. It categorizes key RFCs and active Internet-Drafts into functional areas, explains the relationships between them, and provides context on their evolution. The goal is to help readers understand the current state-of-the-art, select the appropriate specifications for their use cases, and follow the latest security best practices, while also offering a glimpse into the future directions of the framework.

Introduction This document categorizes specifications within the OAuth ecosystem into three groups:

• Published RFCs: Form the cornerstone of current standards and best practices.
• Active Drafts: Represent features and future directions actively being developed by the working group.
• Historical Drafts: Are expired or superseded but provide valuable context for understanding the design decisions and technical evolution of OAuth.

This roadmap is intended to guide implementers, architects, and security professionals through the extensive library of OAuth specifications, helping them select the appropriate documents for their use cases.

Terminology 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. Readers are expected to be familiar with the terms and concepts described in the core OAuth 2.0 Framework .

Core & Foundational Documents

• RFC 6749, The OAuth 2.0 Authorization Framework (S): The seminal specification for OAuth 2.0, defining the core roles (client, resource owner, authorization server, resource server), grant types, and authorization flows.
• RFC 6750, The OAuth 2.0 Authorization Framework: Bearer Token Usage (S): Defines the most common access token type, the "Bearer" token. A bearer token can be used by anyone who possesses it, making its transport and storage security critical.
• draft-ietf-oauth-v2-1, The OAuth 2.1 Authorization Framework (Draft): This effort consolidates and simplifies the original framework for modern applications. It formalizes a decade of security best practices by mandating PKCE, redirect URI exact matching, and the use of the Authorization Code flow. It explicitly deprecates insecure grants like the Implicit Grant and the Resource Owner Password Credentials Grant, providing a more secure baseline for new deployments.

Security Framework & Best Practices

Overall Security Guidance

• RFC 6819, OAuth 2.0 Threat Model and Security Considerations (I): An early comprehensive security document that analyzes various threat models (e.g., token leakage, open redirectors) and proposes countermeasures. While still useful, many of its recommendations have been superseded by RFC9700.
• RFC 9700, OAuth 2.0 Security Best Current Practice (B): The current definitive security guide. It consolidates the latest security lessons and provides a concrete set of recommendations that all modern implementations SHOULD follow.
• draft-ietf-oauth-security-topics-update (Draft): The draft name for the work that eventually became RFC9700, representing the continuous evolution of security guidance within the working group.

Protecting the Authorization Flow

• RFC 7636, Proof Key for Code Exchange (PKCE) (S): Protects the Authorization Code flow from interception attacks. Originally designed for public clients (like mobile apps) that cannot securely store a secret, PKCE is now a BCP for all client types, including confidential ones, as it provides a robust defense-in-depth against code injection.
• RFC 9101, JWT-Secured Authorization Request (JAR) (S): Ensures the integrity and authenticity of authorization request parameters by packaging them into a signed (and optionally encrypted) JWT. This prevents attackers from tampering with parameters like redirect_uri or scope.
• RFC 9126, Pushed Authorization Requests (PAR) (S): Enhances security and privacy by allowing a client to push its authorization request parameters directly to the authorization server via a secure backchannel. This returns a request_uri which the client then sends through the browser. PAR protects request parameters from being exposed to the user agent (browser) or in server logs, and it works very well in combination with JAR for a fully secured request.

Securing Access Tokens (Sender-Constraining)

• RFC 8705, Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (S): A powerful mechanism that provides two functions: first, it defines a strict client authentication method using TLS certificates. Second, it enables the binding of access tokens to a specific client certificate, ensuring that even if a token is stolen, it cannot be used by an attacker who does not possess the client's private key.
• RFC 9449, Demonstrating Proof-of-Possession (DPoP) (S): A lightweight, application-level sender-constraint mechanism. It binds a token to a specific client's public/private key pair without relying on mutual-TLS. This makes it suitable for browser-based applications and other environments where mTLS is difficult to deploy.
• draft-ietf-oauth-refresh-token-expiration (Draft): Provides critical security best practices for refresh tokens, including recommendations for rotation (issuing a new refresh token with each use) and setting expiration policies to mitigate the risks of refresh token leakage.

Mitigating Logical & Implementation Flaws

• RFC 8707, Resource Indicators for OAuth 2.0 (S): Allows a client to specify the intended resource server (API) during the authorization request. This enables the Authorization Server to issue an audience-restricted token, preventing a token intended for one API from being replayed at another.
• RFC 9207, Authorization Server Issuer Identification (S): Prevents "mix-up" attacks where a malicious authorization server could trick a client into sending a code to the wrong token endpoint. It requires the AS to declare its issuer identifier and clients/RSs to validate it.
• draft-ietf-oauth-mix-up-mitigation (Draft): Provides comprehensive strategies to mitigate various "mix-up attacks" where a credential (e.g., a code, token, or client secret) might be sent to the wrong entity, expanding on the protections offered by RFC9207.
• draft-ietf-oauth-cross-device-security (Draft): Specifically analyzes and proposes mitigations for security threats in cross-device flows, such as the Device Authorization Grant (RFC8628).

Advanced Client Authentication

• draft-ietf-oauth-attestation-based-client-auth (Draft): Defines a client authentication method where the client must provide an attestation from a trusted third party (e.g., a device manufacturer or platform vendor), suitable for high-security scenarios where the client's integrity must be verified.
• draft-ietf-oauth-spiffe-client-auth (Draft): Defines client authentication using SPIFFE SVIDs (Verifiable Identity Documents), designed to provide strong, cryptographic workload identity in cloud-native and service mesh environments.

Token Management & Formats

• RFC 7009, Token Revocation (S): Defines an endpoint for clients to proactively invalidate a refresh or access token, for example, when a user logs out.
• RFC 7662, Token Introspection (S): Defines an endpoint for resource servers to check the validity and metadata of a token with the authorization server. This is particularly useful for opaque (non-JWT) tokens.
• RFC 7519, JSON Web Token (JWT) (S): Defines the JWT format, the de facto standard for structured, self-contained tokens in the OAuth ecosystem.
• RFC 8725, JSON Web Token Best Current Practices (B): Provides essential security best practices for implementing and using JWTs, such as algorithm validation (alg header) and claim verification.
  • draft-ietf-oauth-rfc8725bis (Draft): An effort to update RFC8725 with new security advice and clarifications based on implementation experience.
• RFC 9068, JWT Profile for OAuth 2.0 Access Tokens (S): An official profile defining a recommended set of claims (like iss, exp, aud, client_id) for using a JWT as an OAuth 2.0 access token, promoting interoperability.

Client Registration, Metadata & Discovery

• RFC 7591, Dynamic Client Registration (S): Allows OAuth clients to register with an authorization server programmatically, automating the onboarding process.
• RFC 7592, Dynamic Client Registration Management (S): Complements RFC7591 by defining a protocol for updating and deleting client registrations.
• RFC 8414, Authorization Server Metadata (S): Allows an AS to publish its configuration details (like endpoint URLs and supported capabilities) at a well-known URI, enabling dynamic discovery by clients.
• draft-ietf-oauth-client-id-metadata-document (Draft): Proposes a mechanism for clients to also publish a metadata document, declaring their software information and configuration to enhance transparency and security for authorization servers.

Grant Types & Assertion Framework

• RFC 7521, Assertion Framework (S): Provides a general framework for using assertions (like SAML or JWT) for client authentication and as authorization grants. This is foundational for service-to-service communication.
• RFC 7523, JWT Profile for Authorization Grants (S): A concrete implementation of RFC7521 using JWTs as assertions. This allows a client to use a JWT to request an access token without a direct user interaction.
  • draft-ietf-oauth-rfc7523bis (Draft): Aims to update RFC7523 to address ambiguities and align with modern security practices.
• RFC 8628, Device Authorization Grant (S): The "Device Flow," designed for input-constrained devices (like smart TVs or CLIs) that cannot host a web browser for user authentication.
• RFC 8693, Token Exchange (S): A versatile grant type that allows a service to exchange one type of security token for another. This is the cornerstone of modern microservices security, enabling use cases like impersonation (a frontend service acting on behalf of a user) and delegation (a service calling another service with a more restricted token).
• draft-ietf-oauth-identity-assertion-authz-grant (Draft): Proposes a new grant type that allows a client to use an identity assertion (like an ID Token from an external IdP) to obtain an access token, streamlining federated identity scenarios.

Advanced Authorization Capabilities

• RFC 9396, Rich Authorization Requests (RAR) (S): Extends OAuth to allow clients to request structured, fine-grained authorization (e.g., access to specific bank accounts with specific transaction limits) beyond simple string-based scopes.
• RFC 9901, Selective Disclosure for JSON Web Tokens (S): specifies a mechanism for selectively disclosing individual claims within a JSON Web Token (JWT) by replacing them with salted hashes, allowing a holder to reveal only a subset of information to a verifier while maintaining cryptographic proof of the data's integrity and origin.
• draft-ietf-oauth-transaction-tokens (Draft): Explores the use of short-lived tokens bound to a specific transaction to enhance security for high-risk operations like financial payments, building on ideas from RAR and sender-constraining.

Client-Specific Profiles & BCPs

• RFC 8252, OAuth 2.0 for Native Apps (B): Provides best current practices for implementing OAuth 2.0 in native mobile and desktop applications. It recommends using external user agents (like the system browser) and custom URI schemes or claimed "https" schemes for handling redirects.
• draft-ietf-oauth-browser-based-apps (Draft): The definitive guide for implementing OAuth 2.0 in Single-Page Applications (SPAs). It recommends the Authorization Code flow with PKCE and deprecates the Implicit Grant. It also provides guidance on token storage (e.g., using backend-for-frontend patterns) and mitigating threats like Cross-Site Scripting (XSS).
• draft-ietf-oauth-first-party-apps (Draft): Offers specific security and implementation guidance for first-party applications, where the client and authorization server belong to the same entity, allowing for certain optimizations while maintaining security.

Relationship with OpenID Connect While this document focuses on the OAuth 2.0 authorization framework, it is crucial to mention OpenID Connect (OIDC) . OIDC is a simple identity layer built on top of OAuth 2.0 that provides authentication and enables clients to verify the identity of the end-user. Many modern OAuth deployments use OIDC for user login and to obtain an ID Token, and then leverage standard OAuth mechanisms for API authorization using the Access Token. Understanding the distinction and synergy between OAuth (for "what a user can do") and OIDC (for "who the user is") is fundamental for many use cases. It is also worth noting the historical influence of the OpenID Foundation on the IETF OAuth working group. Several key OAuth specifications were heavily inspired by, and are often compatible with, earlier standards from the OpenID Connect suite. For example, the discovery mechanisms in OAuth 2.0 Authorization Server Metadata are based on the earlier OpenID Connect Discovery specification. Similarly, OAuth 2.0 Dynamic Client Registration builds upon its OpenID Connect counterpart. The concept of passing authorization request parameters in a JWT was also first specified in OpenID Connect Core before being formally adopted in the IETF as JWT-Secured Authorization Request (JAR) .

Advanced & Emerging Technologies Specifications in this area often intersect with decentralized identity, Verifiable Credentials (VCs), and privacy-enhancing technologies.

• draft-ietf-oauth-sd-jwt-vc (Draft): Defines how to carry Verifiable Credentials (VCs) using Selectively Disclosable JWTs (SD-JWTs), allowing users to disclose only necessary identity attributes during an OAuth flow, enhancing user privacy.
• draft-ietf-oauth-status-list (Draft): Proposes an efficient and privacy-preserving mechanism for checking the revocation status of credentials (like VCs) at scale.
• draft-ietf-oauth-identity-chaining (Draft): Explores a mechanism to securely pass and link multiple identity and authorization contexts during token exchange, forming a verifiable "identity chain." This is highly relevant for complex delegation scenarios in microservices.
• RFC 9635, Grant Negotiation and Authorization Protocol (S): specifies the Grant Negotiation and Authorization Protocol (GNAP), a flexible mechanism for delegating authorization by allowing a client and an authorization server to negotiate the terms of access to APIs and user information over a series of cryptographically secured interactions.

Historical & Superseded Documents These expired drafts are valuable for understanding the evolution of OAuth. They represent early explorations of ideas, some of which evolved into the standards we use today.

• draft-ietf-oauth-authentication / draft-ietf-oauth-web-delegation: Very early drafts that explored building an authentication layer on top of OAuth 2.0, serving as precursors to OpenID Connect.
• draft-ietf-oauth-v2-http-mac: Proposed a Message Authentication Code (MAC) token type as an alternative to Bearer tokens for stronger request signing, but it was not widely adopted due to complexity.
• draft-ietf-oauth-pop-architecture / draft-ietf-oauth-pop-key-distribution: Laid the early architectural foundation for "Proof-of-Possession" (PoP) tokens, whose core ideas evolved into the more mature mTLS (RFC8705) and DPoP (RFC9449) specifications.
• draft-ietf-oauth-token-binding: An early attempt at sender-constraint that aimed to bind OAuth tokens to the underlying TLS channel, but the underlying Token Binding protocol it depended on was not finalized by the IETF.
• draft-ietf-oauth-closing-redirectors: Specifically discussed and proposed solutions for mitigating the Open Redirector vulnerability, with its ideas being integrated into mainstream security best practices.
• draft-ietf-oauth-use-cases: An early document used to collect and articulate the use cases that shaped the design of OAuth 2.0.
• draft-ietf-oauth-distributed / draft-ietf-oauth-reciprocal: Explored authorization models for distributed and peer-to-peer scenarios, with some concepts finding more mature expression in specifications like Token Exchange (RFC8693).

IANA Considerations This document has no IANA actions.

Security Considerations This document is a roadmap that provides a guide to the OAuth 2.0 family of specifications; it does not define a protocol itself. As such, it does not introduce any new security considerations. The security of an OAuth 2.0 implementation depends on the proper application of the standards and best practices described in the referenced documents. Readers are strongly encouraged to consult the security considerations sections of each individual RFC and draft. In particular, the following documents provide comprehensive security guidance and are considered essential reading for all implementers:

• OAuth 2.0 Security Best Current Practice : The primary and most up-to-date guide for securing OAuth 2.0 deployments.
• OAuth 2.0 for Native Apps : Essential security practices for mobile and desktop applications.
• JSON Web Token (JWT) Best Current Practices : Critical guidance for anyone using JWTs as access tokens or in other contexts.

Implementers should pay close attention to the evolution of security drafts, such as draft-ietf-oauth-v2-1, which aim to simplify and harden the core framework.

Acknowledgements The authors would like to thank Julius Cordes for his valuable review and suggestions.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport. [STANDARDS-TRACK] This document proposes an additional endpoint for OAuth authorization servers, which allows clients to notify the authorization server that a previously obtained refresh or access token is no longer needed. This allows the authorization server to clean up security credentials. A revocation request will invalidate the actual token and, if applicable, other tokens based on the same authorization grant. JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. This specification provides a framework for the use of assertions with OAuth 2.0 in the form of a new client authentication mechanism and a new authorization grant type. Mechanisms are specified for transporting assertions during interactions with a token endpoint; general processing rules are also specified. The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms. Note that this specification only defines abstract message flows and processing rules. In order to be implementable, companion specifications are necessary to provide the corresponding concrete instantiations. This specification defines the use of a JSON Web Token (JWT) Bearer Token as a means for requesting an OAuth 2.0 access token as well as for client authentication. This specification defines mechanisms for dynamically registering OAuth 2.0 clients with authorization servers. Registration requests send a set of desired client metadata values to the authorization server. The resulting registration responses return a client identifier to use at the authorization server and the client metadata values registered for the client. The client can then use this registration information to communicate with the authorization server using the OAuth 2.0 protocol. This specification also defines a set of common client metadata fields and values for clients to use during registration. This specification defines methods for management of OAuth 2.0 dynamic client registrations for use cases in which the properties of a registered client may need to be changed during the lifetime of the client. Not all authorization servers supporting dynamic client registration will support these management methods. OAuth 2.0 public clients utilizing the Authorization Code Grant are susceptible to the authorization code interception attack. This specification describes the attack as well as a technique to mitigate against the threat through the use of Proof Key for Code Exchange (PKCE, pronounced "pixy"). This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The OAuth 2.0 device authorization grant is designed for Internet- connected devices that either lack a browser to perform a user-agent- based authorization or are input constrained to the extent that requiring the user to input text in order to authenticate during the authorization flow is impractical. It enables OAuth clients on such devices (like smart TVs, media consoles, digital picture frames, and printers) to obtain user authorization to access protected resources by using a user agent on a separate device. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual-TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. This document specifies an extension to the OAuth 2.0 Authorization Framework defining request parameters that enable a client to explicitly signal to an authorization server about the identity of the protected resource(s) to which it is requesting access. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that authorization request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that a) the communication through the user agents is not integrity protected and thus, the parameters can be tainted, b) the source of the communication is not authenticated, and c) the communication through the user agents can be monitored. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS) and encrypted with JSON Web Encryption (JWE) so that the integrity, source authentication, and confidentiality properties of the authorization request are attained. The request can be sent by value or by reference. This document defines the pushed authorization request (PAR) endpoint, which allows clients to push the payload of an OAuth 2.0 authorization request to the authorization server via a direct request and provides them with a request URI that is used as reference to the data in a subsequent call to the authorization endpoint. This document specifies a new parameter called iss. This parameter is used to explicitly include the issuer identifier of the authorization server in the authorization response of an OAuth authorization flow. The iss parameter serves as an effective countermeasure to "mix-up attacks". This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows for the detection of replay attacks with access and refresh tokens. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. This specification defines a mechanism for the selective disclosure of individual elements of a JSON data structure used as the payload of a JSON Web Signature (JWS). The primary use case is the selective disclosure of JSON Web Token (JWT) claims. Informative References This document gives additional security considerations for OAuth, beyond those in the OAuth 2.0 specification, based on a comprehensive threat model for the OAuth 2.0 protocol. This document is not an Internet Standards Track specification; it is published for informational purposes. OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case and how native apps and authorization servers can implement this best practice. JSON Web Tokens, also known as JWTs, are URL-safe JSON-based security tokens that contain a set of claims that can be signed and/or encrypted. JWTs are being widely used and deployed as a simple security token format in numerous protocols and applications, both in the area of digital identity and in other application areas. This Best Current Practices document updates RFC 7519 to provide actionable guidance leading to secure implementation and deployment of JWTs. OpenID Foundation n.d.

References

Normative References

Informative References