OAuth / OIDC – Flow Recap Notes¶
Core Definitions¶
- SPA is logged in ⟺ it has a valid access token
- Auth Server is logged in ⟺ browser has an auth-server session cookie
- These are independent states
1. Authorization Code Flow (+ PKCE)¶
Purpose - User login - Delegated access on behalf of a user
Characteristics
- User is present
- Browser used only for redirects
- Tokens issued via /token (back-channel)
Flow
1. SPA checks: no access token → logged out
2. SPA redirects to /authorize
3. Auth Server:
- if no session → user enters ID/password
- creates auth-server session cookie
4. Auth Server issues authorization code
5. SPA exchanges code → gets access token (+ ID token if OIDC)
6. SPA is now logged in (has access token)
Token represents - Client acting on behalf of a user
2. SSO with Multiple SPAs¶
Key idea - SSO works via auth-server cookie reuse - Tokens are not shared between SPAs
Scenario
- SPA 1 logs in first → auth-server cookie created
- SPA 2 starts with no token → redirects to /authorize
- Auth Server sees existing session → skips login UI
- SPA 2 gets its own access token
Result - One login prompt - Separate tokens per SPA
3. OIDC (on top of Auth Code Flow)¶
What OIDC adds
- scope=openid
- ID Token
ID Token
- Used by the client (SPA/BFF)
- Represents user identity
- Never used by APIs
- Issued at /token, not /authorize
4. Client Credentials Flow¶
Purpose - Service-to-service authentication - No user involved
Characteristics - No browser - No consent - No UI
Flow
1. Service calls /token with grant_type=client_credentials
2. Auth Server authenticates client (secret or private key)
3. Access token issued
Token represents - The application itself - No user context
Typical use - Background jobs - RabbitMQ workers - Reconciliation with external APIs
5. Token Exchange / OBO (On-Behalf-Of)¶
Purpose - Service A calls Service B as the same user
Characteristics - No user interaction at runtime - Uses an existing user access token - Issues a new token per hop
Flow 1. Service A receives user access token 2. Service A sends token to Auth Server 3. Auth Server: - validates original token - enforces admin-defined delegation rules - narrows scopes - changes audience 4. New token issued for Service B
Consent - User consents once to the client - Admin defines service delegation - No consent screens between services
6. JWT Bearer Grant (Assertion-Based Impersonation)¶
Purpose - Headless impersonation against external SaaS
Used by - DocuSign - Google Service Accounts
Characteristics - No redirects - No browser - Signed JWT assertion - One-time user or admin consent (out-of-band)
Token represents - Application acting as a user
Not - Client Credentials - OBO
7. Scope vs Audience¶
- Scope → what is allowed
invoice.read- Audience (
aud) → where the token may be used invoice-service
Both must be enforced by APIs.
8. Hard Rules¶
- Tokens must be re-minted per hop
- ID Tokens must never be sent to APIs
- Client Credentials must never impersonate users
- OAuth issues tokens; APIs enforce meaning
One-Line Mental Map¶
Auth Code (+ PKCE) → user login OIDC → identity (ID token) Client Credentials → service identity Token Exchange → service acting as user JWT Bearer Grant → external impersonation Scopes → what Audience → where