What does OAuth 2.1 change compared with OAuth 2.0?
It consolidates and simplifies OAuth 2.0: PKCE is required for all authorization code clients, redirect URIs must be compared exactly, the implicit (and password) grant is removed, bearer tokens may not be sent in URI query strings, refresh tokens must be sender-constrained or one-time-use, and the client type definitions are simplified.
OAuth 2.1 is not a new protocol. It folds a decade of extensions and security advice (PKCE, the native-apps and browser-apps guidance, the security best practice) back into one document so that implementers no longer have to read a dozen RFCs to get it right.
| Change | Why |
|---|---|
| PKCE required for every client using the authorization code flow | Stops code interception and injection for all clients, not only public ones. |
| Exact string matching of redirect URIs | Closes the wildcard and prefix-matching attacks. |
| Implicit grant removed | Tokens in the browser URL; replaced by code + PKCE. |
| Password grant omitted | It shares the user's password with the client. |
| No bearer tokens in query strings | URLs leak through logs, history and Referer headers. |
| Refresh tokens sender-constrained or one-time-use | A stolen refresh token becomes useless or its misuse becomes detectable. |
| Simpler public/confidential client definitions | Less room for misclassification. |
Note that OAuth 2.1 is still an IETF Internet-Draft, not yet a published RFC, although most of its rules are already required by RFC 9700 and widely implemented.
Go deeper:
oauth.net: OAuth 2.1 — a summary of every difference from OAuth 2.0.- IETF Datatracker: The OAuth 2.1 Authorization Framework — the current draft and its status.