Every time you click "Sign in with Google" instead of creating yet another password, OAuth 2.0 is doing the work. It is one of the most widely used and most misunderstood protocols on the web. This guide explains what OAuth actually does, the pieces involved, and the flow that makes delegated access secure.
The problem OAuth solves
Suppose an app wants to access your Google Calendar. The naive solution — giving the app your Google password — is terrible: the app could do anything, and you would have to change your password to revoke it. OAuth solves this by letting you grant the app limited, revocable access without ever revealing your password.
The four roles
- Resource owner — you, the user who owns the data.
- Client — the application requesting access.
- Authorization server — issues tokens after you approve (e.g. Google’s login).
- Resource server — holds the data and accepts the token (e.g. the Calendar API).
The authorization code flow
In the most common flow, the app redirects you to the provider, where you log in and approve the requested permissions. The provider sends the app a short-lived authorization code, which the app exchanges — server to server, with its secret — for an access token. The app then uses that token to call the API on your behalf. Your password never touches the app.
Tokens and scopes
An access token is the key the app uses to make requests; it is deliberately short-lived. A refresh token lets the app obtain new access tokens without bothering you again. Scopes limit what the token can do — read-only calendar access, for instance — so apps get only the permissions they actually need.
Authorization, not authentication
The crucial nuance: OAuth 2.0 is about authorization — granting access to resources — not authentication, which is proving who you are. "Sign in with Google" actually relies on OpenID Connect, a thin identity layer built on top of OAuth. Confusing the two leads to insecure designs, so it is worth keeping the distinction clear.