Don't Panic — OAuth 2.0

OAuth 2.0 is the thing that lets you click a "Connect to Google" button and give an app access to just your calendar, without ever typing your Google password into it. It is an authorization framework: a set of rules for how one application gets limited, revocable access to your data on another service.

Before it, the way to let an app read your mail was to hand over your username and password and hope for the best. The app then had everything, indefinitely, and changing your password was the only way to take it back. OAuth replaces that with a token, a short-lived credential that says "this app may read this mailbox and nothing else" and that you can revoke on its own.

The design rests on three ideas. The first is the set of four roles: the resource owner (you), the client (the app), the authorization server (which issues tokens), and the resource server (which holds the data and checks tokens). Keep those four straight and most of the confusion goes away.

The second is the authorization code flow with PKCE, the exchange to use whenever a person is present in a browser. The app sends you to the authorization server, you approve, it returns a short-lived code, and the app swaps that code plus a proof it generated earlier for a token. The code travels through the browser; the token does not.

The third is that an access token is a bearer credential: whoever holds it can use it. So it travels only over TLS, never sits in a URL, and never lands in a log.

Here is the part that catches people out: OAuth does not log anyone in. It answers "may this app do this", not "who is this person". Identity is a separate layer called OpenID Connect, built on top of OAuth. A tutorial that uses plain OAuth for "sign in with..." is leaning on behavior the framework never promised.

The second trap is assuming that a valid token means the request is allowed. The resource server still has to confirm the token was issued for it, has not expired, and carries the right scope, and then that the specific record belongs to the caller. Most OAuth security failures are one of those checks, skipped.

For the full picture of roles, flow, and token handling, read the Introduction, with the Slides as the compressed version. The Cheatsheet has the grant-selection table and an error-to-cause lookup for when something returns invalid_grant. The Practice tab walks through deriving a PKCE challenge by hand, and Field Notes covers what teams get wrong once they are past the diagram.

Don't Panic — OAuth 2.0

Relevant careers