How the specifications evolve
OAuth's rules come from documents written many years apart. RFC 6749 described the implicit grant in 2012, and RFC 9700 told clients in 2025 that they should not use it. PKCE arrived in 2015, mainly for mobile applications, and is now expected of almost every client. Some of the extensions in Advanced OAuth are recent RFCs, and a newer document, OAuth 2.1, gathers many of these changes into one.
Reading OAuth well means knowing how those documents relate to each other: which one is current, which is still changing, and how firmly each sentence is meant.
From draft to RFC
Most OAuth specifications come from the OAuth working group of the Internet Engineering Task Force (IETF), an open standards organization whose work happens largely on public mailing lists and at regular meetings. A specification begins as an Internet-Draft, which anyone can submit. If the working group agrees to take it on, it becomes a working group draft with a name such as draft-ietf-oauth-v2-1 and is revised in numbered versions: -00, -01, and so on. A draft expires six months after its last revision unless a newer one replaces it, and it has no formal standing. It can be cited only as work in progress.
When the editors and chairs believe a draft is ready, the chairs issue a working group last call, a final period, often two weeks, in which the group raises any remaining objections. The draft then goes through a last call to the whole IETF and a review by the Internet Engineering Steering Group (IESG), and is finally published by the RFC Editor as a numbered Request for Comments, or RFC.
An RFC never changes after publication. Mistakes found later are recorded as errata beside it, each marked as reported, verified, held for a future update, or rejected, while the RFC's own text stays exactly as it was. Larger changes arrive as new RFCs that state which earlier ones they update or obsolete. RFC 6749 obsoletes RFC 5849, the OAuth 1.0 document. RFC 9700 updates RFC 6749, RFC 6750, and RFC 6819 without replacing them, so anyone reading RFC 6749 alone today gets an incomplete picture.
RFCs also differ in kind. Standards Track documents, such as RFC 6749 and RFC 7636 for PKCE, define protocols. Best Current Practice documents record the community's current advice under a BCP number that can gather several RFCs on one subject. RFC 9700 is BCP 240, and BCP 212 includes both RFC 8252, on native applications, and RFC 10017, on browser-based applications. Informational documents, such as RFC 5849, describe something without making it a standard, and Experimental ones, such as RFC 7592 for managing dynamic registrations, are published to gain experience before anyone commits to them.
Registries and other standards bodies
Protocols need names that never collide. When the device authorization grant needed a grant type, or token exchange needed identifiers for kinds of tokens, those values were registered with the Internet Assigned Numbers Authority (IANA). Its OAuth Parameters registries list request and response parameter names, access token types such as Bearer and DPoP, authorization response types, extension error codes, client authentication methods, PKCE methods, and metadata fields. They also list the urn:ietf:params:oauth: names used for extension grant types, such as urn:ietf:params:oauth:grant-type:device_code, and for token types, such as urn:ietf:params:oauth:token-type:jwt. A new entry needs a published specification and approval from designated experts. When an unfamiliar parameter appears in a request, the registry is the place to find which document defines it.
Not every specification in this area comes from the IETF. The OpenID Foundation, a separate non-profit organization, develops OpenID Connect, the sign-in layer built on OAuth 2.0, and the FAPI security profiles that Advanced OAuth described. Its working groups publish Implementer's Drafts, and then Final Specifications approved by a vote of the Foundation's members. OpenID Connect Core 1.0 became final in 2014, and the FAPI 2.0 Security Profile in 2025. The Foundation also runs the conformance tests and certification program described in Interoperability and conformance testing. Many people take part in both organizations, and each regularly builds on the other's documents.
OAuth 2.1
Years of extensions and security advice left a reader of RFC 6749 with homework: read the original, then RFC 6750, RFC 7636, RFC 8252, RFC 9700, and more, and work out which parts of the original no longer apply. OAuth 2.1 is the working group's effort to fold those documents into one, and OAuth security best practices listed the defaults it changes. Following one of those changes back through the earlier documents shows what the consolidation gathers. PKCE is a good example:
| When | Document | What it said about PKCE |
|---|---|---|
| 2015 | RFC 7636 | Defined it, mainly to protect public clients such as native apps. |
| 2017 | RFC 8252, BCP 212 | Required it for public native app clients. |
| 2025 | RFC 9700, BCP 240 | Required it for public clients and recommended it for confidential clients. |
| Later | OAuth 2.1 | Makes it part of the authorization code grant itself, used by clients and enforced by servers, with narrow exceptions. |
Each row tightened the one before without contradicting it, which is how much of OAuth's guidance has changed. A mechanism appears as an option, becomes required for the clients that need it most, becomes recommended for everyone, and finally becomes part of the framework's default. OAuth 2.1 aims to stay compatible with OAuth 2.0 as current best practice already uses it, rather than to add new features. Any Internet-Draft can still change before it is published, which is why a careful reference to one names the version that was read.
Reading requirement keywords
Most of these specifications declare near the start that certain words carry precise meanings, as defined in BCP 14, which consists of RFC 2119 and RFC 8174:
| Keyword | Meaning |
|---|---|
| MUST, REQUIRED, SHALL | An absolute requirement. |
| MUST NOT, SHALL NOT | An absolute prohibition. |
| SHOULD, RECOMMENDED | There may be valid reasons to do otherwise in particular circumstances, but the full implications must be understood and weighed first. |
| SHOULD NOT, NOT RECOMMENDED | The behavior may be acceptable or even useful in particular circumstances, but only after its implications have been weighed. |
| MAY, OPTIONAL | Truly optional. An implementation must still work with one that made the other choice. |
RFC 8174 added a clarification that matters when reading closely: the words carry these meanings only when written in capitals. A lowercase "must" in a recent RFC is ordinary English. Documents written before that clarification are not always consistent, so their lowercase words deserve a second look.
The levels map onto decisions described in earlier lessons. RFC 9700 says the password grant MUST NOT be used, which leaves no circumstance open. It says clients SHOULD NOT use the implicit grant unless token injection is prevented and token leakage is mitigated, which leaves a narrow path for anyone able to show those conditions are met. For browser-based clients, RFC 10017 later closed that path with a MUST NOT. RFC 9700 also says public clients MUST use PKCE and that PKCE is RECOMMENDED for confidential clients, so a confidential client without it is not broken, but its developers need a reason. RFC 2119 itself notes that the force of these words depends on the kind of document they appear in, and profiles add another layer: FAPI turns many of OAuth's SHOULDs and MAYs into requirements for the deployments that adopt it.
OAuth 2.0 began in 2012 as a framework, and every document since has extended, corrected, or consolidated it with one goal: letting an application like the printer reach your photos without your password. The printing company's next request is a different one. It wants to know who you are, and From delegated access to sign-in explains why an access token cannot tell it and how OpenID Connect, built on the same exchanges, does.