Roles, Tokens & the Authorization Code Flow

Authorization, Not Authentication

OAuth 2.0 lets a user grant a third-party app limited access to their resources on another service — WITHOUT sharing their password. It solves delegated authorization (what can this app do), not authentication (who is this user) — OpenID Connect (OIDC), built on top, adds the identity layer for that.

The Four Roles

Resource Owner (the user) · Client (the third-party app) · Authorization Server (issues tokens after consent) · Resource Server (hosts the protected data, validates tokens). In "Sign in with Google": you're the owner, the app is the client, Google's auth service is the authorization server, Gmail's API is the resource server.

Scopes & Consent

A scope is one granular permission ("read your email") — the user sees and consents to exactly what's being requested, not an all-or-nothing grant. Requesting overly broad scopes both raises user suspicion and increases blast radius if the token leaks — request only what's actually needed (least privilege).

The Authorization Code Flow

1. App redirects user to Authorization Server with client_id, scope, redirect_uri, state
2. User logs in and approves the requested scopes
3. Authorization Server redirects back with a short-lived authorization CODE
4. App's BACKEND exchanges the code (+ client secret) for an access token — server-to-server
5. App calls the Resource Server with: Authorization: Bearer <access_token>

The token exchange happens server-to-server, never through the browser — this is why it's the recommended flow. The state parameter (generated by the client, verified on return) protects against CSRF-style attacks on the redirect.