OAuth 2.1 and the Authorization Code Flow with PKCE

Before delegated authorization existed as a standard, a third-party application that wanted to act on a user's behalf against another service had exactly one option: ask the user to type their actual password into the third-party app, which then stored it and used it directly. This handed the third party a standing, full-strength credential with no ability to scope what it could do, no way to revoke just that one integration without changing the password everywhere else it was used, and no visibility for the user into which applications currently held it. OAuth exists to remove that requirement entirely — a user can grant a specific, limited, revocable permission to a third-party application without that application ever seeing the user's actual password.

OAuth 2.1 is a consolidation of OAuth 2.0's accumulated best practice into the specification itself: the authorization code flow with PKCE becomes the required flow for essentially every client type, and flows that OAuth 2.0's ecosystem had already learned were unsafe in practice — the implicit flow, and the resource owner password credentials grant — are removed rather than merely discouraged. This lesson covers the flow that survives that consolidation, in the detail an engineer implementing or integrating against it actually needs.

PKCE in particular is worth being precise about, because it is widely summarized in ways that miss what it actually does. It is not primarily a defense against cross-site request forgery — a separate mechanism, the state parameter, handles that. PKCE defends against a different, more specific threat: an authorization code being intercepted by a party other than the client that originally requested it, and that interceptor successfully exchanging it for a token. Getting this distinction right is the difference between understanding PKCE and merely being able to recite that it involves a code_verifier and a code_challenge.

Analogy🏏Cricket

🏏 Think of it like cricket: A star player wants a specific sports-nutrition brand to have limited, temporary access to his official training data for a single sponsored campaign — not his full medical history, not permanent access, just this one dataset for this one campaign's duration. The old way of handling this would have the player simply hand over his personal login credentials for the board's entire player-management portal to the brand's marketing team, who could then see everything the player himself could see, indefinitely, until someone remembered to change the password. A modern sponsorship data-sharing agreement instead routes through the board itself: the brand requests access, the player explicitly approves exactly what is being shared and for how long, and the board issues the brand a scoped, time-limited credential valid only for that specific dataset — with the player's actual login never leaving his own hands at any point in the process. Just as the modern agreement lets a player grant a brand limited, revocable access without ever handing over his actual login, OAuth lets a user grant a third-party application limited, revocable access without ever handing over their actual password. Just as the old full-credential-handover approach gave the brand everything indefinitely with no easy way to revoke just that one relationship, a password directly shared with a third party grants everything that password unlocks, indefinitely, until the password itself is changed everywhere. The insight is that delegated, scoped, revocable access is a fundamentally different and safer arrangement than sharing the underlying credential itself, and that difference is the entire reason OAuth exists as a standard rather than being left to each application's own ad hoc password-sharing convention.