OAuth Standards History and Timeline - What Each RFC and BCP Updated, Obsoleted, or Left Unchanged

First Published: 2026-11-09
Last Updated: 2026-11-09

RFC 6749 (the OAuth 2.0 Authorization Framework) was published on October 13, 2012. As of November 9, 2026, there are no RFCs that replace (obsolete) RFC 6749. Three RFCs update RFC 6749: RFC 8252 (2017), RFC 8996 (2021), and RFC 9700 (2025). RFC 10017 and RFC 10027, published in August 2026, are Best Current Practices (BCPs) but do not update RFC 6749. OAuth 2.1 is currently an Internet-Draft (draft-ietf-oauth-v2-1-17) in the IETF's OAuth Working Group, and is not yet an RFC.

This article is a timeline that details the dates on which various OAuth standards documents were published, and how they updated, replaced, or left unchanged previous RFCs. It covers documents from RFC 5849 (OAuth 1.0, published on April 20, 2010) through RFC 10070 (published on November 7, 2026), and includes drafts as of the check date. Each row describes the changes for the client, authorization server, and resource server, to the extent verifiable in the RFC itself. OpenID Connect, being a layer built on top of OAuth, has only four rows related to OpenID Foundation specifications.

All dates and update relationships were verified as of November 9, 2026, using the RFC Editor, IETF Datatracker, and OpenID Foundation websites. This article does not provide explanations of OAuth flows, nor does it address the compatibility of specific products.

Related articles on this site:

Background and Method of Creating the OAuth Standards Timeline

The OAuth standards are not a single document, but rather a collection of RFCs, BCPs, and drafts. RFC 6749 defines four grant types for obtaining access tokens (authorization code, implicit, resource owner password credentials, and client credentials). Subsequent RFCs have added new grant types and endpoints, and updated portions of RFC 6749. The relationship between an RFC and previous RFCs is indicated in the "Updates" and "Obsoletes" fields in the RFC Editor's metadata. This article will use these two fields as columns in a timeline.

Sources Used in This Article

The rows in the timeline were primarily drawn from the following resources:

RFC Editor — Metadata for each RFC (the month of publication, status, updates, obsoletes, updated_by, and obsoleted_by in https://www.rfc-editor.org/rfc/rfcNNNN.json), as well as the full text of the RFCs. The RFC Editor provides publication dates through the month. The RFC Editor queue was checked at https://queue.rfc-editor.org/api/v1/queue.xml.
IETF Datatracker — Publication records for RFCs (published_rfc event), relationships indicating which BCPs contain which RFCs (contains relationship), records of draft revisions (new_revision event), the status of drafts and working groups, WG milestones, and the history of charters, all extracted from its JSON API and HTML pages. Datatracker timestamps are in UTC.
Draft Text — The full text of each version of the OAuth 2.1 draft found in https://www.ietf.org/archive/id/, along with the dates in their headers.
OpenID Foundation — The full text of the specifications found in https://openid.net/specs/, as well as their headers and the approval announcement pages.

Which Documents Become Rows

This article gives rows to the OAuth WG RFCs that are relevant to the implementation of clients, authorization servers, and resource servers. Specifically, it includes documents pertaining to grant and flow mechanisms, token handling, client authentication, metadata, and security best practices (BCPs). RFC 8996, which is not an OAuth WG document, is included because it updates RFC 6749 and RFC 6750. Only three versions of OAuth 2.1 (-00, -16, and -17) are listed. Only the DAWN working group, whose charter was approved on October 22, 2026, is included from the IETF working groups. Specifications from the OpenID Foundation are listed in four rows: the final version of OpenID Connect Core 1.0 (2014), the version incorporating errata set 2 (2023), the final version of FAPI 2.0 Security Profile (2025), and the final version of OpenID Connect Ephemeral Subject Identifier 1.0 (2026).

This article does not cover all RFCs from the OAuth Working Group. For example, RFC 7592 (Dynamic Client Registration Management Protocol), which is designated as experimental, is not included.

Date Types

This article categorizes dates into the following types:

Datatracker Date — The Date column in RFC rows refers to the UTC date of the published_rfc event in Datatracker. For example, the event for RFC 10070 is 2026-11-07T20:51:14Z. The date displayed on the Datatracker page may sometimes differ from the UTC date by one day (as shown in the example of -17 for OAuth 2.1). This article will use UTC dates.
RFC Editor Month — The RFC Editor Month column indicates the publication month in the RFC Editor metadata. The RFC Editor does not have specific dates; it only indicates months. In the 30 RFCs that have rows in this article and in RFC 9701, the Datatracker date and the RFC Editor month always fall in the same month.
Draft Revision Date — The Date column in draft rows refers to the UTC date of the new_revision event in Datatracker. The draft header also includes a date. For OAuth 2.1 -17, the header date is 31 October 2026, while the event is recorded as 2026-10-31T04:16:32Z. However, the Datatracker document page displays Last updated as 2026-10-30. This article will not combine these three dates into a single date.
OpenID Foundation Revision Date and Announcement Date — The Date column in OpenID Foundation rows refers to the date in the specification's header. The date of the approval announcement is listed separately in the same row under the Event column. These represent two distinct events.

How to Read the Tables

The columns in the timeline table are as follows:

Date — Refers to the dates listed under "Date Types" above.
RFC Editor Month — Only used for rows pertaining to RFCs. Rows that are not RFCs have —.
Event — Describes what happened on that day in a single sentence.
Document — Lists the RFC number. For RFCs included in BCPs, the BCP number is also listed. For drafts, the name and version are listed; for WGs, the name is listed.
Status — Indicates the status from the RFC Editor’s metadata (Proposed Standard, Best Current Practice, Informational). Drafts have the WG status from Datatracker (WG Document); WGs have the group status (Active). OpenID Foundation specifications have Final. Note that the Final designation for OpenID Foundation specifications is separate from the Standards Track stages in the IETF.
Updates and Obsoletes — Lists the values from the RFC Editor’s metadata for the updates and obsoletes fields. Updates indicates modifications or additions to a previous RFC, and the previous RFC remains valid. Obsoletes indicates that a previous RFC is being replaced. This article does not combine these two terms. Even if a draft’s text anticipates obsolescence, this column will not list it. This is because drafts are not RFCs and do not have RFC Editor metadata.
What Changed for the Receiver — Describes what changed on the client, authorization server, or resource server side, either through a summary of the RFC or from the text of specific sections. This article does not list anything that it has not verified in the text. Uppercase terms like MUST, SHOULD, and MAY are written as they appear in the original text. Even when this article rephrases requirements, it includes the original term in parentheses. This article does not treat lowercase terms as normative language.
Source — Lists the pages of the source material.

This article uses four terms from the language used in other articles in the same series to indicate the status of the material.

Stated: The documentation contains a statement regarding the matter.
No statement found: Despite searching using different search terms and examining different categories of documentation, no relevant statement could be found. This does not necessarily indicate that the matter is absent or does not occur.
Sources disagree: The documentation from two different sources provides conflicting statements regarding the same matter. This includes cases where the statements directly contradict each other, as well as cases where the scope, strength, or subject matter differs, and the text does not settle which statement applies. This article will present both statements and their sources without designating either as incorrect.
Inference: This is an inference made by this article, and is not a statement found in any of the documentation. This article says in the same sentence that it is an inference.

What This Article Leaves to Other Articles

This article does not cover the following:

The history of the JWT and JOSE specifications and the status of alg values. This is covered in the JWT and JOSE timeline article. While RFC 9068 (JWT access tokens) and RFC 9449 (DPoP) are standards within OAuth, they are addressed with a single row here, but their history is detailed in the JWT and JOSE timeline article. RFC 9701 (JWT response for token introspection) does not have a row. RFC 10070 has a single row as an update to OAuth client authentication.
A list of ongoing draft specifications related to AI agent authorization, along with tables of interim meetings in the OAuth Working Group and their outcomes. This is covered in Where AI Agent Authorization Standards Stand. This article limits its scope to the three documents in the RFC Editor queue, one in IESG Evaluation, the versions and the WG milestone of OAuth 2.1, and a single row regarding DAWN.
The requirements outlined in RFC 10017 and RFC 10027, and their corresponding configurations within Amazon Cognito. This is covered in Browser-Based Apps and Cross-Device Flows on Amazon Cognito.
Which OAuth documents each version of the Model Context Protocol (MCP) specification required. This is covered in Model Context Protocol Specification Version Timeline. Delegation chains as defined in RFC 8693 are covered in Identity Lifecycle for AI Agents.
The subject identifier types within OpenID Connect and the corresponding behavior on the AWS side. A separate article on ephemeral subject identifiers within this series (When sub Changes on Every Sign-In) addresses this.
Future date predictions and outcomes of meetings. Working Group milestone dates are given as goals that the Working Group has set, together with the check date.

OAuth Standards Historical Timeline (Updates from 2010-04-20)

The timeline is divided into four tables, organized by era. Within each table, rows are listed in ascending order by date. For rows on the same date, they are sorted by the time of events recorded in Datatracker.

2010–2015 — OAuth 1.0, OAuth 2.0, the Threat Model, and PKCE

OAuth 1.0 was released as an Informational RFC. In 2012, RFC 6749 replaced it. Over the following three years, token revocation, assertion, client registration, PKCE, and introspection were each added as separate RFCs. None of these RFCs updates RFC 6749.

Date	RFC Editor Month	Event	Document	Status	Updates	Obsoletes	What Changed for the Receiver	Source
2010-04-20	April 2010	The OAuth 1.0 protocol was published as an RFC.	RFC 5849	Informational	—	—	Defined how a client can access server resources on behalf of a resource owner, and outlined the procedures for granting access without the user providing credentials. RFC 5849 is not a Standards Track specification.	RFC Editor / Datatracker
2012-10-13	October 2012	The authorization framework for OAuth 2.0 was published as an RFC.	RFC 6749	Proposed Standard	—	RFC 5849	Defined four grant types, as well as authorization and token endpoints. RFC 6749 replaced RFC 5849.	RFC Editor / Datatracker
2012-10-13	October 2012	The usage of bearer tokens was published as an RFC.	RFC 6750	Proposed Standard	—	—	Defined three methods for sending bearer tokens to resource servers: the `Authorization` header, the body of a form, and a URI query. Any party holding a bearer token can use it without demonstrating possession of a key.	RFC Editor / Datatracker
2013-01-08	January 2013	The threat model for OAuth 2.0 was published as an RFC.	RFC 6819	Informational	—	—	Summarized security considerations beyond those outlined in RFC 6749, presented as a threat model. RFC 6819 is not a Standards Track specification.	RFC Editor / Datatracker
2013-08-22	August 2013	Token revocation was published as an RFC.	RFC 7009	Proposed Standard	—	—	Added a revocation endpoint to the authorization server, allowing clients to notify the server when refresh tokens or access tokens are no longer needed.	RFC Editor / Datatracker
2014-02	—	OpenID Connect Core 1.0 reached Final status within the OpenID Foundation. The date is the month that the specification's references section gives for `OpenID Connect Core 1.0 (final)`. Version with errata set 1 was released in November 2014.	OpenID Connect Core 1.0	Final	—	—	Defined a method for conveying user authentication results via an ID token, built on top of OAuth 2.0. The OpenID Foundation specification does not have an Updates or Obsoletes relationship with IETF specifications.	OpenID Connect Core 1.0
2015-05-19	May 2015	An assertion framework, along with two profiles – one for SAML 2.0 and one for JWT – were published as RFCs on the same day.	RFC 7521 / RFC 7522 / RFC 7523	Proposed Standard	—	—	Defined a framework for using assertions in client authentication and authorization grants. RFC 7522 is a profile for SAML 2.0 assertions, and RFC 7523 is a profile for JWT assertions. RFC 10070 updated these three RFCs in November 2026. The history of the JWT aspect is detailed in the JWT and JOSE timeline article.	RFC Editor 7521 / RFC Editor 7522 / RFC Editor 7523
2015-07-09	July 2015	Dynamic client registration was published as an RFC.	RFC 7591	Proposed Standard	—	—	Defined how a client can register with an authorization server by sending its metadata and receiving a client identifier.	RFC Editor / Datatracker
2015-09-16	September 2015	PKCE was published as an RFC.	RFC 7636	Proposed Standard	—	—	Defined PKCE, a protection against authorization code interception attacks on public clients using the authorization code grant. RFC 7636 does not update RFC 6749.	RFC Editor / Datatracker
2015-10-19	October 2015	Token introspection was published as an RFC.	RFC 7662	Proposed Standard	—	—	Defined how a protected resource can query an authorization server to determine if a token is valid and to obtain metadata about the token.	RFC Editor / Datatracker

2016–2021 — The Native Apps BCP, Metadata, the Device Grant, Token Exchange, Mutual TLS, JAR, and PAR

During the period from 2016 to 2021, the first RFC updating RFC 6749 was published: RFC 8252, a Best Current Practice (BCP) for native applications. RFC 8996 was also published, a BCP that deprecated TLS 1.0 and TLS 1.1, and updated numerous RFCs, including RFC 6749 and RFC 6750. The remaining RFCs published during this time all lacked entries in the "Updates" and "Obsoletes" fields. Furthermore, the working group (WG) draft for OAuth 2.1 was initiated during this period.

Date	RFC Editor Month	Event	Document	Status	Updates	Obsoletes	What Changed for the Receiver	Source
2017-10-04	October 2017	OAuth 2.0 for Native Apps was published as a BCP.	RFC 8252 (BCP 212)	Best Current Practice	RFC 6749	—	Its abstract says that authorization requests from native apps should only be made through external user agents, primarily the user's browser, and Section 4 requires (MUST) native apps to use an external user agent. Section 6 requires (MUST) public native app clients to implement PKCE and requires (MUST) authorization servers to support PKCE for those clients.	RFC Editor / Datatracker
2018-06-28	June 2018	Authorization Server Metadata was published as an RFC.	RFC 8414	Proposed Standard	—	—	It defined the format of metadata that allows clients to obtain the location and functionality of authorization server endpoints.	RFC Editor / Datatracker
2019-08-17	August 2019	Device Authorization Grant was published as an RFC.	RFC 8628	Proposed Standard	—	—	It defined a method for clients on devices without a browser or with limited input to obtain user authorization by using a different user agent on another device.	RFC Editor / Datatracker
2020-01-15	January 2020	Token Exchange was published as an RFC.	RFC 8693	Proposed Standard	—	—	It defined a protocol for requesting and obtaining security tokens from authorization servers, including tokens for impersonation and delegation.	RFC Editor / Datatracker
2020-02-29	February 2020	Mutual TLS (RFC 8705) and Resource Indicators (RFC 8707) were published on the same day as RFCs.	RFC 8705 / RFC 8707	Proposed Standard	—	—	RFC 8705 defined client authentication using mutual TLS, as well as access and refresh tokens associated with a client certificate. RFC 8707 defined a method for clients to indicate the desired resource to the authorization server through request parameters.	RFC Editor 8705 / RFC Editor 8707
2020-07-30	—	Version -00 of the OAuth 2.1 WG draft was released. Datatracker records that this draft replaced the individual draft `draft-parecki-oauth-v2-1`.	`draft-ietf-oauth-v2-1-00`	WG Document	—	—	As a draft, there are no changes that take effect for the receiver.	Datatracker history
2021-03-23	March 2021	A BCP was released deprecating TLS 1.0 and TLS 1.1.	RFC 8996 (BCP 195)	Best Current Practice	84 RFCs, including RFC 6749 and RFC 6750	RFC 5469 / RFC 7507	The relevant RFCs were updated to replace mentions of a minimum version of TLS 1.0 or TLS 1.1 with TLS 1.2. The statement that TLS 1.0 was the most widely deployed was removed without replacement. This type of statement can be found in RFC 6749, §1.6.	RFC Editor / Datatracker
2021-08-21	August 2021	JWT-Secured Authorization Request (JAR) was published as an RFC.	RFC 9101	Proposed Standard	—	—	It defined a method for including authorization request parameters within a JWT, signing it with JWS, and encrypting it with JWE to provide integrity, sender authentication, and confidentiality.	RFC Editor / Datatracker
2021-09-15	September 2021	Pushed Authorization Requests (PAR) was published as an RFC.	RFC 9126	Proposed Standard	—	—	It defined a method for clients to send the contents of an authorization request directly to the authorization server and to reference the received request URI in subsequent calls to the authorization endpoint. RFC 10070 updated this RFC on 2026-11-07.	RFC Editor / Datatracker
2021-10-21	October 2021	JWT Access Token Profile was published as an RFC.	RFC 9068	Proposed Standard	—	—	It defined a profile for authorization servers to issue access tokens in the JWT format and for resource servers to receive them. The history of this profile is documented in the timeline article for JWT and JOSE.	RFC Editor / Datatracker

2022–2025 — Issuer Identification, RAR, DPoP, Step Up, the Security BCP, and FAPI 2.0

The central focus during this period was RFC 9700 (BCP 240), published on January 30, 2025. RFC 9700 updates RFC 6749, RFC 6750, and RFC 6819. No RFCs were replaced. Details on the changes will be provided later in the "Current Overview," along with the original text.

Date	RFC Editor Month	Event	Document	Status	Updates	Obsoletes	What Changed for the Receiver	Source
2022-03-18	March 2022	An RFC was published regarding the identification of issuers for authorization servers.	RFC 9207	Proposed Standard	—	—	Defined a method for explicitly identifying the authorization server (issuer identifier) by including the `iss` parameter in the authorization response. This is a measure against mix-up attacks.	RFC Editor / Datatracker
2023-05-30	May 2023	An RFC was published regarding fine-grained authorization requests (RAR).	RFC 9396	Proposed Standard	—	—	Defined a method for including fine-grained authorization data in OAuth messages using the `authorization_details` parameter.	RFC Editor / Datatracker
2023-09-07	September 2023	DPoP was published as an RFC.	RFC 9449	Proposed Standard	—	—	Defined a method for proving possession of a key at the application layer, binding access tokens and refresh tokens to the sender. Details regarding the history are left to the timeline article for JWT and JOSE.	RFC Editor / Datatracker
2023-09-08	September 2023	An RFC was published regarding step-up authentication requests.	RFC 9470	Proposed Standard	—	—	Defined a mechanism for the resource server to inform the client that the authentication event associated with the access token does not meet its authentication requirements, and how to satisfy those requirements.	RFC Editor / Datatracker
2023-12-15	—	A version of OpenID Connect Core 1.0 incorporating errata set 2 was released. The date is the header date of this version.	OpenID Connect Core 1.0	Final	—	—	This is a revised version that corrects errors from the 2014 Final version. This article does not detail the contents of errata set 2.	OpenID Connect Core 1.0
2025-01-30	January 2025	A Best Current Practice (BCP) for OAuth 2.0 security was published.	RFC 9700 (BCP 240)	Best Current Practice	RFC 6749 / RFC 6750 / RFC 6819	—	Requires public clients to use PKCE (MUST), discourages the use of implicit grant (SHOULD NOT), and prohibits resource owner password credentials grant (MUST NOT). It also requires exact string matching against pre-registered redirect URIs, except for localhost ports of native apps (MUST) and prohibits sending access tokens in the URI query (MUST NOT).	RFC Editor / Datatracker
2025-02-22	—	A Final version of the FAPI 2.0 Security Profile was released. The date is the `Published` date in the header of this version. The OpenID Foundation’s approval announcement was released earlier, on February 19, 2025.	FAPI 2.0 Security Profile	Final	—	—	This is a security profile built on top of OAuth 2.0. This article does not detail the profile's requirements.	FAPI 2.0 Security Profile / Approval announcement
2025-04-23	April 2025	An RFC was published regarding protected resource metadata.	RFC 9728	Proposed Standard	—	—	Defined the format of metadata that clients and authorization servers use to obtain information for interacting with protected resource.	RFC Editor / Datatracker

2026 to the Check Date — RFC 10027, RFC 10017, OAuth 2.1 -16 and -17, ESID, DAWN, and RFC 10070

In August 2026, two BCPs were released, both of which had empty "Updates" and "Obsoletes" fields. RFC 10017 was incorporated into BCP 212, which already included RFC 8252. On November 7, 2026, RFC 10070 was released, updating RFC 7521, RFC 7522, RFC 7523, and RFC 9126. During this period, OAuth 2.1 saw the release of versions -16 and -17, but remained in draft form as of the check date.

Date	RFC Editor Month	Event	Document	Status	Updates	Obsoletes	What Changed for the Receiver	Source
2026-08-11	August 2026	A Best Current Practice (BCP) for cross-device flow security was released.	RFC 10027 (BCP 247)	Best Current Practice	—	—	This document summarizes threats and mitigation strategies, as well as guidance on protocol selection, for cross-device flows. It does not update RFC 6749.	RFC Editor / Datatracker
2026-08-21	August 2026	A BCP for browser-based applications using OAuth 2.0 was released.	RFC 10017 (BCP 212)	Best Current Practice	—	—	This document outlines threats, security considerations, and best practices for creating browser-based applications. It does not update RFC 6749. Section 7.2 states that authorization servers MUST NOT issue access tokens in the authorization response, and browser-based clients MUST NOT use the implicit grant type. BCP 212 contains two RFCs: RFC 8252 and RFC 10017.	RFC Editor / Datatracker
2026-09-03	—	Draft -16 of OAuth 2.1 was released. The header date is `3 September 2026`, and the Datatracker event is `2026-09-03T00:22:00Z`.	`draft-ietf-oauth-v2-1-16`	WG Document	—	—	As this is a draft, there are no changes that affect the receiver.	Datatracker history
2026-10-07	—	The final version of OpenID Connect Ephemeral Subject Identifier 1.0 was released. The date is the header date. The OpenID Foundation’s approval announcement was released on 2026-10-08.	OpenID Connect Ephemeral Subject Identifier 1.0	Final	—	—	This document defines a third subject identifier type, `ephemeral`, in which the `sub` claim in an ID token has a different value for each authentication request. Another article in the same series (When sub Changes on Every Sign-In) covers the impact on the receiver.	ESID final text / Approval announcement
2026-10-22	—	The IESG approved the charter for the DAWN Working Group. DAWN is a Working Group within the Internet Area and is separate from the OAuth Working Group.	DAWN	Active	—	—	There are no changes to the OAuth RFCs or drafts.	DAWN charter history / DAWN WG
2026-10-31	—	Draft -17 of OAuth 2.1 was released. The header date is `31 October 2026`, and the Datatracker event is `2026-10-31T04:16:32Z`. The Datatracker document page displays `Last updated` as `2026-10-30`.	`draft-ietf-oauth-v2-1-17`	WG Document	—	—	As this is a draft, there are no changes that affect the receiver. The draft abstract states that it replaces RFC 6749 and RFC 6750, but the RFC Editor metadata will not change until it is published as an RFC.	Datatracker
2026-11-07	November 2026	An RFC updating JWT client authentication and assertion grant was released.	RFC 10070	Proposed Standard	RFC 7521 / RFC 7522 / RFC 7523 / RFC 9126	—	For client authentication using JWT, the `aud` claim must be only the issuer identifier of the authorization server (MUST). The authorization server must reject JWTs that do not contain its own issuer identifier as the sole `aud` value (MUST). SAML Bearer assertions must not be used for client authentication in new applications (MUST NOT).	RFC Editor / Datatracker

Current Overview of OAuth Standards

This chapter outlines, as of November 9, 2026 (the check date), which RFCs updated or replaced which, based on the metadata provided by the RFC Editor. Furthermore, it examines how RFC 9700 modifies RFC 6749 and which RFCs each Best Current Practice (BCP) contains.

Who Updates Whom

The following table shows the obsoleted_by and updated_by fields from the RFC Editor’s metadata for several key RFCs, as of November 9, 2026.

RFC	Status	Obsoleted By	Updated By	Source State
RFC 5849	Informational	RFC 6749	—	Stated
RFC 6749	Proposed Standard	—	RFC 8252 / RFC 8996 / RFC 9700	Stated
RFC 6750	Proposed Standard	—	RFC 8996 / RFC 9700	Stated
RFC 6819	Informational	—	RFC 9700	Stated
RFC 7521	Proposed Standard	—	RFC 10070	Stated
RFC 7522	Proposed Standard	—	RFC 10070	Stated
RFC 7523	Proposed Standard	—	RFC 10070	Stated
RFC 9126	Proposed Standard	—	RFC 10070	Stated

The obsoleted_by field for RFC 6749 is empty. Since its publication on October 13, 2012, RFC 6749 has never been replaced. Three RFCs update RFC 6749: RFC 8252 and RFC 9700, which are BCPs for OAuth, and RFC 8996, which is a BCP for TLS. The updates and obsoletes fields for RFC 10017 and RFC 10027 are both empty.

OAuth RFC Update and Obsolescence Relationships

The solid arrows in the diagram represent the "Updates" and "Obsoletes" relationships as defined in the RFC Editor’s metadata. Dashed lines represent the relationship that the abstract of the OAuth 2.1 draft states, which is not reflected in the RFC Editor’s metadata.

What RFC 9700 Changed in RFC 6749 and RFC 6750

The abstract of RFC 9700 says that it updates and expands the threat models and security advice outlined in RFC 6749, RFC 6750, and RFC 6819. It also indicates that certain modes of operation deemed less secure or insecure have been deprecated. The key passages are as follows, all taken directly from the text of RFC 9700:

§2.1 states the following regarding the comparison of redirect URIs:

When comparing client redirection URIs against pre-registered URIs, authorization servers MUST utilize exact string matching except for port numbers in localhost redirection URIs of native apps (see Section 4.1.3).

§2.1.1 states the following regarding PKCE:

Public clients MUST use PKCE [RFC7636] to this end, as motivated in Section 4.5.3.1.
For confidential clients, the use of PKCE [RFC7636] is RECOMMENDED, as it provides strong protection against misuse and injection of authorization codes as described in Section 4.5.3.1.
Authorization servers MUST support PKCE [RFC7636].

§2.1.2 states the following regarding the implicit grant:

clients SHOULD NOT use the implicit grant (response type token) or other response types issuing access tokens in the authorization response

This passage continues by adding the condition that this applies unless access token injection is prevented and leakage paths have been mitigated.

§2.2.2 states the following regarding refresh tokens for public clients:

Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation as described in Section 4.14.

§2.4 states the following regarding the resource owner password credentials grant:

The resource owner password credentials grant [RFC6749] MUST NOT be used.

§4.3.2 states the following regarding query parameters in RFC 6750:

Clients MUST NOT pass access tokens in a URI query parameter in the way described in Section 2.3 of [RFC6750].

RFC 9700 does not rewrite the main text of RFC 6749. RFC 6749 remains a valid document, defining both the implicit grant and the resource owner password credentials grant. However, as a Best Current Practice (BCP), RFC 9700 states that these grants should not be used (SHOULD NOT) or must not be used (MUST NOT). Reading only RFC 6749, these two grants may still appear to be viable options.

The BCPs and the RFCs They Contain

The numbers assigned to BCPs refer to one or more RFCs. Datatracker tracks which RFCs each BCP contains, using a contains relationship. As of November 9, 2026, the data is as follows:

BCP	RFCs It Contains	Published (Datatracker, UTC)	Updates	Source
BCP 212	RFC 8252 / RFC 10017	2017-10-04 / 2026-08-21	RFC 8252 updates RFC 6749. RFC 10017 updates none.	BCP 212
BCP 240	RFC 9700	2025-01-30	RFC 6749 / RFC 6750 / RFC 6819	BCP 240
BCP 247	RFC 10027	2026-08-11	None	BCP 247
BCP 195	RFC 8996 / RFC 9325 / RFC 9852	—	RFC 8996 updates 84 RFCs, including RFC 6749 and RFC 6750.	BCP 195

BCP 212 contains two RFCs: RFC 8252 (from 2017, concerning native applications) and RFC 10017 (from 2026, concerning browser-based applications). RFC 10017 does not replace RFC 8252. Neither RFC has any entries in the "Obsoletes" field. BCP 195 is a BCP related to TLS, and this article only lists RFC 8996 as a row in the timeline (the dates for RFC 9325 and RFC 9852 are not included in the table).

The RFC Editor status of an RFC in a BCP is Best Current Practice, a separate category from RFCs designated as Proposed Standard. When a BCP updates an RFC, the update relationship is recorded in the "Updates" field, just as it is for other RFCs.

The Same Day, the Same Month, and Three Dates for One Draft

For RFC rows, the Datatracker date and the RFC Editor month fall in the same month for all 30 RFCs that have rows in this article and for RFC 9701. In some cases, documents were released on the same day. Examples include RFC 6749 and RFC 6750 (2012-10-13), RFC 7521, RFC 7522, and RFC 7523 (2015-05-19), RFC 8705 and RFC 8707 (2020-02-29), and RFC 9700 and RFC 9701 (2025-01-30). RFC 9449 (2023-09-07) and RFC 9470 (2023-09-08) were released one day apart.

In the draft series, a single version may contain three different dates. In OAuth 2.1 -17, the header lists 31 October 2026, a Datatracker event is listed as 2026-10-31T04:16:32Z, and the Last updated date on a Datatracker document page is 2026-10-30. This article infers (Inference) that the page displays the UTC event in US Pacific Time, and that the difference is not a disagreement between sources.

Where the Drafts Stand on the Check Date

This chapter describes the status of various OAuth documents that had not yet been finalized as RFCs as of November 9, 2026, in the scope covered by this article. A list of ongoing draft specifications is available in Where AI Agent Authorization Standards Stand.

The OAuth 2.1 Draft

The OAuth 2.1 draft is currently at -17 (as of November 9, 2026). According to Datatracker, its status is Active, I-D Exists, and WG Document. The abstract of -17 says:

This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749 and the Bearer Token Usage in RFC 6750.

This is draft text and is not yet in effect. The obsoleted_by fields in RFC 6749 and RFC 6750 are currently empty, as of the check date.

The following table lists the dates for three versions of OAuth 2.1 that have been included in the timeline. Datatracker records 18 versions, ranging from -00 to -17.

Version	Header Date	Datatracker Event (UTC)	Note
-00	30 July 2020	2020-07-30T15:32:44Z	First version of the WG draft
-16	3 September 2026	2026-09-03T00:22:00Z	—
-17	31 October 2026	2026-10-31T04:16:32Z	Latest version as of the check date

The OAuth Working Group has set a milestone with a target date of December 31, 2026 (as confirmed on November 9, 2026).

Submit “OAuth 2.1 Authorization Framework’ to IESG

This is a Working Group milestone and does not represent the date of submission to the IESG or the date of RFC publication.

RFC Editor Queue, IESG Evaluation, and WG Document

The following table shows the status of OAuth Working Group documents nearing RFC publication as of November 9, 2026.

Stage	Document	Version in the Stage	Date	What the Record Shows	Source
RFC Editor Queue	`draft-ietf-oauth-status-list`	-20	2026-06-04	Date received in the queue. The queue state is `first_editor`.	RFC Editor queue
RFC Editor Queue	`draft-ietf-oauth-identity-chaining`	-15	2026-06-22	Date received in the queue.	RFC Editor queue
RFC Editor Queue	`draft-ietf-oauth-rfc8725bis`	-10	2026-08-25	Date received in the queue. The queue state is `blocked`, awaiting `draft-ietf-jose-deprecate-none-rsa15` (normative reference).	RFC Editor queue
IESG Evaluation	`draft-ietf-oauth-sd-jwt-vc`	-26	2026-11-06	The IESG state in Datatracker is `IESG Evaluation`. The date reflects the UTC time of the document's last update.	Datatracker
WG Document	`draft-ietf-oauth-v2-1`	-17	2026-10-31	The status in the Working Group is `WG Document`. The IESG status is `I-D Exists`.	Datatracker

The draft that updated RFC 7523 (draft-ietf-oauth-rfc7523bis-11) was published as RFC 10070 on November 7, 2026, and is not in the queue. The timeline article for JWT and JOSE describes the history of this draft in the queue. While draft-ietf-oauth-status-list and draft-ietf-oauth-identity-chaining have the latest versions (-21 and -17, respectively) according to Datatracker, the queue records the versions shown in the table above.

Standards Stages in the OAuth Working Group as of the Check Date

The diagram depicts only the five documents listed in the table above, as well as RFC 10070. It does not include predictions or stages that have not been verified.

DAWN Is Not the OAuth Working Group

DAWN (Discovery of Agents With Names) is an IETF Working Group whose charter was approved by the IESG on October 22, 2026. Its status in Datatracker is Active, and its parent group is the Internet Area. The OAuth WG is neither the parent of DAWN nor the same group. The record on October 22, 2026, in the charter history states IESG has approved the charter. The timestamp 2026-10-22T16:33:16Z in Datatracker's group record indicates when the record was updated, and is not the time of approval. This article has not checked the documents of the DAWN Working Group as of the check date.

Frequently Asked Questions about OAuth Standards History

This chapter answers common questions regarding the evolution and timeline of OAuth standards, drawing information from the timeline and tables presented within.

Is OAuth 2.1 a standard?

As of November 9, 2026, OAuth 2.1 is not yet a standard. It is currently an Internet-Draft in the IETF's OAuth Working Group. The latest version is draft-ietf-oauth-v2-1-17 (header 31 October 2026). Its Datatracker state is WG Document, and its IESG state is I-D Exists. The OAuth Working Group has set a target date of December 31, 2026, for submission to the IESG.

Has RFC 6749 been replaced?

RFC 6749 has not been replaced. The obsoleted_by field in the RFC Editor's metadata for RFC 6749 is empty. The RFCs that updated RFC 6749 are three: RFC 8252, RFC 8996, and RFC 9700. Since the updated RFCs remain valid, when reading RFC 6749, it is necessary to also review these three documents. While a draft of OAuth 2.1 states that it replaces RFC 6749, that draft is not yet in effect.

What did RFC 9700 change in RFC 6749?

RFC 9700 did not modify the main body of RFC 6749, but instead added requirements as a Best Current Practice (BCP). Public clients must use PKCE (MUST), and authorization servers must support PKCE (MUST). Clients should not use the implicit grant type (SHOULD NOT). The resource owner password credentials grant type is prohibited (MUST NOT). Authorization servers must compare client redirect URIs against pre-registered URIs using exact string matching (MUST). However, this does not apply to the port number of redirect URIs used by native applications on localhost. The original text is in "What RFC 9700 Changed in RFC 6749 and RFC 6750" in this article.

Why does BCP 212 contain two RFCs?

BCP numbers can refer to one or more RFCs. Datatracker records that BCP 212 contains both RFC 8252 (October 4, 2017, native applications) and RFC 10017 (August 21, 2026, browser-based applications). RFC 10017 does not replace RFC 8252, and both remain part of BCP 212. Similarly, RFC 9700 is associated with BCP 240, and RFC 10027 is associated with BCP 247, each of which contains only one RFC.

When did PKCE become required for public clients?

PKCE became required in stages. RFC 7636 (September 16, 2015) defined PKCE, but did not update RFC 6749. Section 6 of RFC 8252 (October 4, 2017) required (MUST) public native app clients to implement PKCE. Section 2.1.1 of RFC 9700 (January 30, 2025) requires (MUST) the use of PKCE for public clients, and recommends it (RECOMMENDED) for confidential clients.

Do RFC 10017 and RFC 10027 update RFC 6749?

No, they do not. In the RFC Editor's metadata, both RFC 10017 and RFC 10027 have empty fields for updates and obsoletes. Both are Best Current Practices (BCPs); RFC 10017 is included in BCP 212, and RFC 10027 is included in BCP 247.

Is DAWN an OAuth working group?

DAWN is not an OAuth working group. Instead, DAWN is a working group in the Internet Area, whose charter was approved by the IESG on October 22, 2026. It is a separate group from the OAuth working group. This article's timeline has only one row for DAWN, and that row does not change the OAuth RFCs or drafts.

Summary

This article lists the standard OAuth documents, from RFC 5849 (2010-04-20) for OAuth 1.0 to RFC 10070 (2026-11-07) and the drafts as of the check date, organizing them by the Updates and Obsoletes fields in the RFC Editor metadata and by dates from Datatracker.

RFC 6749 has never been replaced. RFC 6749 replaced RFC 5849 for OAuth 1.0, and as of November 9, 2026, the obsoleted_by field for RFC 6749 itself is empty.

Three RFCs have updated RFC 6749. These are RFC 8252 (BCP 212), RFC 8996 (BCP 195), and RFC 9700 (BCP 240). These updates do not replace RFC 6749, so when reading RFC 6749, it is important to also review these three documents.

BCPs that update RFC 6749 do not replace it. RFC 9700, for example, updates RFC 6749 without rewriting its text, specifying that implicit grants should not be used (SHOULD NOT), resource owner password credentials grants are prohibited (MUST NOT), and public clients must use PKCE (MUST). RFC 10017 and RFC 10027 do not update RFC 6749.

BCP 212 contains two RFCs. They are RFC 8252 and RFC 10017. BCP 240 contains RFC 9700, and BCP 247 contains RFC 10027.

OAuth 2.1 is currently a draft. As of November 9, 2026, it exists as a Working Group (WG) document, draft-ietf-oauth-v2-1-17, and the proposed replacements for RFC 6749 and RFC 6750 have not yet taken effect. The Working Group's target date is December 31, 2026.

Read dates by type. RFC dates refer to the dates listed in Datatracker and the months listed by the RFC Editor. Drafts have the header date, the UTC date of the Datatracker event, and the date displayed on the page. OpenID Foundation specifications have both a version date and an announcement date.

This timeline will be updated as the OAuth standards continue to evolve.

In addition, there are related history and timeline articles on this site, so please take a look if you are interested.

Tools on this site:

OAuth 2.0 and OIDC Flow Visualizer and PKCE Generator - Authorization Code, Client Credentials, and S256 Challenge Builder

References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi