A Comprehensive Roadmap for OAuth 2.0 Standards and Drafts

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 November 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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.¶

      +-------------------------------------------------+
      |             Core: RFC 6749 (OAuth 2.0)          |
      |             Core: RFC 6750 (Bearer Token)       |
      +------------------------+------------------------+
                               |
            +------------------+------------------+
            |                                     |
+-----------v------------+             +-----------v-----------+
|   OAuth 2.1 (Draft)    |             |Security BCP (RFC 9700)|
|(Consolidates & Hardens)|             | (Overall Guidance)    |
+------------------------+             +-----------------------+
            |
+-----------+------------------------------------------------------------+
| Foundational Extensions & Security Mechanisms                          |
+------------------------------------------------------------------------+
|                                                                        |
|  - RFC 7636 (PKCE): Protects code flow                                 |
|  - RFC 9126 (PAR) / RFC 9101 (JAR): Protect authorization requests     |
|  - RFC 9449 (DPoP) / RFC 8705 (mTLS): Sender-constrains tokens         |
|  - RFC 8707 (Resource Indicators): Prevents token misuse               |
|  - RFC 7519 (JWT)/ RFC 9068(JWT AT Profile): Token format & profile    |
|  - RFC 8414 (AS Metadata): Enables server discovery                    |
|                                                                        |
+------------------------------------------------------------------------+
            |
+-----------+------------------------------------------------------------+
| Advanced Capabilities & Grant Types                                    |
+------------------------------------------------------------------------+
|                                                                        |
|  - RFC 8693 (Token Exchange): Service-to-service delegation            |
|  - RFC 8628 (Device Grant): Input-constrained devices                  |
|  - RFC 9396 (RAR): Fine-grained authorization                          |
|                                                                        |
+------------------------------------------------------------------------+

   Figure 1: High-Level Relationship of Core OAuth 2.0 Specifications

2. 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 [RFC8174].¶

Readers are expected to be familiar with the terms and concepts described in the core OAuth 2.0 Framework [RFC6749].¶

3. 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.¶

4. Security Framework & Best Practices

5. 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.¶

6. 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.¶

7. 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.¶

8. 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.¶

9. 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.¶

10. Relationship with OpenID Connect

While this document focuses on the OAuth 2.0 authorization framework, it is crucial to mention OpenID Connect (OIDC) [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 [RFC8414] are based on the earlier OpenID Connect Discovery specification. Similarly, OAuth 2.0 Dynamic Client Registration [RFC7591] 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) [RFC9101].¶

11. 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.¶

12. 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).¶

13. IANA Considerations

This document has no IANA actions.¶

14. 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 [RFC9728]: The primary and most up-to-date guide for securing OAuth 2.0 deployments.¶

• OAuth 2.0 for Native Apps [RFC8252]: Essential security practices for mobile and desktop applications.¶

• JSON Web Token (JWT) Best Current Practices [RFC8725]: 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.¶

15. Acknowledgements

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

16. References

Appendix A. References

Authors' Addresses