OAuth Flows

A scheduling app wants to read your work calendar. The old way was to ask for your email password, which means handing a third party unlimited access to everything, forever, revocable only by changing that password everywhere. The modern way sends you to your provider, where you approve a specific scope of access, and the app receives a credential that reads calendars, expires, and can be revoked from a settings page without touching your password. OAuth 2.0 exists for exactly that difference, and once you see the problem it was built for, the protocol's shape stops looking arbitrary.

The first thing this track fixes is a persistent confusion: OAuth is authorization, not authentication. It answers "may this application act on this user's behalf, for this scope", not "who is this user". Applications that treat a successful OAuth flow as proof of identity have a real vulnerability, not a style problem, and the correct fix is OpenID Connect later in this pillar rather than a clever workaround. Getting this straight first makes the rest of the protocol read as a series of deliberate choices.

Those choices are defences. The authorization-code flow keeps the access token off the front channel: the browser only ever carries a short-lived code, which the application exchanges for a token over a direct back-channel call. That still leaves a public client — a mobile app or a single-page app, which cannot keep a secret — vulnerable to having its code intercepted, so PKCE binds the code to the client that started the flow by way of a verifier only that client knows. The state parameter ties the response back to a request you initiated, which is what stops a forged callback, and exact redirect-URI matching stops a code being delivered somewhere it should not go. You will walk the flow, then choose the right one for a given client type and justify it.