OAuth stands for Open Authorization — despite the common name, it is an authorization protocol (delegated access), not authentication. OpenID Connect (OIDC) adds authentication on top.
OAuth 1.0 was designed only for web browsers; OAuth 2.0 extends to apps, APIs, and non-browser flows.
Roles
| Role | Who | Example |
|---|---|---|
| Resource Owner | the user | you |
| Client | the app wanting access | a photo app |
| Authorization Server (AS) | issues tokens | Google, Okta, PingFederate |
| Resource Server (RS) | holds the data | Google Drive API |
Credentials/grants are made of Scope and Claim:
- Scope — what can be accessed (
read:photos,openid profile email) - Claim — key-value facts about the user inside a token/ID token
User authenticates against the auth server only once — the same token then accesses every microservice that trusts that auth server (if allowed).
Grant Types
Authorization Code (+ PKCE) — the default for user login
User App (Client) Authorization Server
|── 1. "Log in with Google" ───────────>|
| |── 2. login + consent
|<── 3. redirect to app with ?code ────|
| |── 4. POST /token ───────>|
| | (code + client_secret |
| | + code_verifier) |── 5. verify ──> tokens
| |<── access + refresh + |
| | id_token ─────────────|
The authorization code travels through the browser (visible, brief, one-time); the token exchange happens server-to-server (back-channel) — tokens never touch the browser URL. This front-channel/back-channel split is the core design idea.
PKCE (code_challenge/code_verifier): the client generates a random
verifier, sends its hash in step 1, and the verifier itself in step 4.
An interceptor who steals the code can't exchange it without the verifier.
Required for public clients (SPAs, mobile) — now recommended everywhere.
Client Credentials — machine to machine
No user involved. Standard for service-to-service API calls.
Refresh Token
Exchange a long-lived refresh token for a new access token without re-prompting the user. See Sessions, Tokens & JWT.
Deprecated / avoid
- Implicit — tokens in the browser URL fragment; superseded by auth-code + PKCE
- Resource Owner Password — app collects the user's password directly; only for legacy first-party migration
Device Code — TVs/consoles/CLI
Device shows a code; user authorizes on a second device; the first device
polls /token until approved.
OpenID Connect (OIDC)
Thin identity layer on OAuth 2.0 that turns it into an authentication protocol:
- Adds the
id_token— a JWT proving who logged in, when, how (sub,iss,aud,auth_time,amr) access_tokenis for the Resource Server ("what may I access");id_tokenis for the Client ("who is this")- Standard endpoints:
/.well-known/openid-configuration(discovery),/userinfo, JWKS for signature verification
OAuth 2.0 ── "Can this app access my photos?" (authorization)
OIDC on OAuth ── "Is this Nitin? Prove it." (authentication)
SSO relationship
OAuth/OIDC is how consumer/web federation works; enterprises historically used SAML for the same purpose — see SSO for SAML, Active Directory, and IAP.