What is OAuth 2.1?

OAuth 2.1, explained#

OAuth 2.0 (RFC 6749, 2012) solved a real problem: apps were asking for people's passwords so they could call APIs for them. With OAuth, the person signs in at the service, approves what the app may do, and the app receives an access token instead. Over the following decade a series of follow-up RFCs and security best-practice documents fixed weaknesses in the original. OAuth 2.1 gathers those fixes into one document.

The main changes from 2.0 are removals. The implicit grant, which returned tokens in the browser's URL, is gone. The resource owner password credentials grant, where the app collects the password anyway, is gone. PKCE becomes required for the authorization code flow. Redirect URIs must match exactly, not by prefix. Bearer tokens may not be sent in query strings. Refresh tokens for public clients must be sender-constrained or used once and rotated.

The flow that remains is the authorization code flow. The app sends the person to the authorization server with its client ID, a redirect URI, the scopes it wants and a PKCE challenge. The person signs in and approves. The server redirects back with a short-lived code. The app exchanges the code, plus the PKCE verifier, for an access token and usually a refresh token.

OAuth 2.1 is still an Internet-Draft rather than a numbered RFC, but its rules are already what careful servers enforce, and the MCP authorization specification requires authorization servers to implement it.

For example, a calendar app wants to read your project deadlines. It sends you to the project tool's consent screen asking for work.read. You approve, the tool redirects back with a code, and the app exchanges it for a one-hour token it can refresh. You never typed your project tool password into the calendar app.