OAuth 2.0’s specification is dense, but the core idea it solves is simple: letting an application access a user’s data on another service, without that application ever seeing the user’s actual password.
The Flow, in Plain Terms
- Your app redirects the user to the service (e.g., Google) to log in directly, on Google’s own site
- The user authenticates and approves specific permissions (“allow this app to see your email address”)
- Google redirects back to your app with a short-lived authorization code
- Your app’s backend exchanges that code (plus a secret only your backend knows) for an access token
- Your app uses the access token to call Google’s API on the user’s behalf, without ever handling their Google password
GET https://api.google.com/userinfo Authorization: Bearer ya29.a0AfH6...
Access Tokens vs Refresh Tokens
Access tokens are deliberately short-lived (often an hour) to limit damage if one leaks — a refresh token, stored more securely and used far less frequently, lets your app silently obtain a new access token without forcing the user to log in again every hour.
Why the Authorization Code Step Exists at All
The intermediate “authorization code” step (rather than handing back the access token directly in the browser redirect) exists specifically so the actual token exchange happens server-to-server, using a client secret the browser never sees — protecting the access token from being exposed in browser history or referrer headers.