skip to content

What is OAuth 2.1 assembled from, and why is it a consolidation rather than a new protocol?

level: middleimportance: should knowfreq 44%

answer

  1. a collection, not an invention
  2. four documents restated as one
  3. SHOULD becomes MUST
  4. no new parameter, endpoint or version flag
  5. already following the BCP means an audit

basics

~20 s

OAuth 2.1 restates RFC 6749 together with the security best current practice, the PKCE document and the native-application document as one text. It invents no endpoint, parameter or token type; it deletes two grants, tightens several rules and collects the rest.

solid answer

~40 s

OAuth 2.1 is an editorial consolidation with teeth. It folds RFC 6749 together with RFC 9700 (the OAuth 2.0 security best current practice), RFC 7636 (PKCE) and RFC 8252 (native applications) into one document, and where those said SHOULD it often says MUST. The deltas against RFC 6749 are short to list: the implicit and resource owner password credentials grants are gone; PKCE is required on the authorization-code grant; `redirect_uri` is compared by exact string match; refresh tokens must be sender-constrained or rotated with replay detection; and an `access_token` may not travel in a query string. No new endpoint, parameter, error code or token type appears, and nothing on the wire announces a version. A team already following the best current practice therefore faces an audit rather than a rewrite.

code

http · 3 lines
http
GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz
    &redirect_uri=https%3A%2F%2Fallotment.example%2Fcallback%2F HTTP/1.1
Host: as.allotment-society.example

go deeper

for a junior

Recall that 2.1 is the same protocol tightened up, not a replacement to learn from scratch, and that the endpoints and parameters you already know are unchanged.

for a middle

Name the documents it consolidates and two or three of the deltas, and be able to say that no new endpoint, parameter or error code appears anywhere in it.

for a senior

Show where the audit actually bites — exact redirection-URI comparison against a deployment that registered patterns, and a proof key that only the public clients were ever sending.

for a principal

Decide what conformance means for your estate when the wire carries no version marker, and what evidence you would accept that a deployment meets it.

## What 2.1 is made of OAuth 2.1 is not a redesign. It restates the OAuth 2.0 authorization framework together with the documents the community wrote around it, as one text with one set of requirements: - **RFC 6749**, the framework itself — the four parties, the endpoints, the parameters, the grants, the error codes. - **RFC 7636**, the proof-key extension for the authorization-code grant. - **RFC 8252**, the guidance for applications running natively on a device. - **RFC 9700**, the OAuth 2.0 security best current practice, where most of the behavioural tightening already lived. Nothing on the wire is invented. There is no new endpoint, no new request parameter, no new error code, no new token type, and no version negotiation — a request does not announce which version the client believes it is speaking. Conformance is a property of what a deployment accepts and what a client sends, which is why an authorization server can be described as supporting 2.1 while still accepting an RFC 6749-era flow from an old client. ## The delta, in full Measured against RFC 6749 alone, the list is short enough to say out loud in an interview. | Change | Relative to RFC 6749 | |---|---| | Implicit grant | removed | | Resource owner password credentials grant | removed | | PKCE on the authorization-code grant | required, with a narrow carve-out | | `redirect_uri` comparison | exact string match | | Refresh tokens | sender-constrained, or rotated with replay detection | | `access_token` in a query string | not permitted | Every row already existed somewhere as a MUST or a SHOULD. What 2.1 does is collect them and, in several cases, raise the strength. The best current practice says clients SHOULD NOT use the implicit grant and 2.1 removes it. That document makes PKCE a MUST only for public clients and 2.1 extends the requirement. Its refresh-token requirement is scoped to public clients and 2.1 states it more broadly. Attributing 2.1's strength back to the older document is the classic misquote here. ## Why exact matching is the row that bites `redirect_uri` comparison is the change most likely to break a working, well-intentioned integration, because the old permissiveness was something people built on. Exact string matching means the registered value and the received value are compared **as characters**, before any reasoning about what the two URIs mean: - a trailing slash is a different string; - an added query parameter is a different string; - a percent-encoding difference is a different string; - a wildcard subdomain or a registered prefix is not a match at all. The failure also lands in an awkward place. When the redirection URI does not match a registered one, the authorization server must not redirect the user agent to it — there is no verified destination to send an error to — so the error surfaces at the authorization server in front of the resource owner rather than inside the client's own error handling. A deployment that registered one pattern and served many tenants through it has to register each URI instead. There is a documented exception concerning the port number of a loopback redirect for an application running natively on a device, which is a subject of its own. ## What this means for a team Two teams get very different answers to the question of how much work 2.1 is. 1. **A team already following the best current practice has an audit.** Confirm no client is registered for or using the removed grants. Confirm the proof key is sent by every authorization-code client rather than only the public ones. Confirm redirection URIs are registered literally. Confirm refresh-token handling meets one of the two allowed shapes. Confirm nothing carries an `access_token` in a URL. 2. **A team running an integration wired up from a decade-old tutorial has a migration**, and probably a product conversation, because the two removed grants are exactly what those tutorials taught. The second case is common in small, long-lived sites — the ones where the login was written once, worked, and was never opened again. The tutorial that produced it is often still online and still ranks well, which is why this material keeps arriving in interviews as confidently wrong rather than absent. ## The interview signal The question sorts candidates quickly. A weak answer treats 2.1 as a new protocol with a compatibility story and reaches for migration language about clients that cannot be upgraded. A strong answer says it is a consolidation, names two or three deltas without hesitating, and is careful about which document each requirement came from and how strong it was there — because getting that wrong is precisely how a team talks itself into believing it already complies.

  • Which 2.1 requirement is most likely to break a long-lived integration that already follows the best current practice?
    Exact-string comparison of `redirect_uri`. A deployment that registered one pattern per tenant, or relied on a trailing slash or an extra query parameter being tolerated, fails the moment the comparison becomes literal — and it fails at the authorization endpoint, before there is any verified destination an error could be redirected to.
  • 2.1 says a refresh token must be sender-constrained or rotated with replay detection. Whose requirement was that already?
    RFC 9700 states it, but scoped to public clients. Repeating it as though the best current practice imposed it on every client is a common misquote, and broadening it is part of what 2.1 does. How rotation and replay detection are actually built is a separate subject from the version delta.

saying these in an interview costs you the question

  • Says OAuth 2.1 is a new protocol that breaks OAuth 2.0 clients.
  • Thinks OAuth 2.1 introduced PKCE.
  • Expects new endpoints or a separate metadata document for 2.1.
  • Treats prefix or wildcard matching of redirect_uri as still acceptable.
  • Says an access token in a query string is fine if it is short-lived.
  • Assumes a client that works against 2.0 automatically meets 2.1.