Mental model#
OAuth delegates access to a protected resource; OpenID Connect adds an identity layer for authentication. The authorization server, client, resource server, user agent, access token, and ID token have different roles and trust boundaries.
Mechanism and state flow#
- Register exact client and redirect metadata and choose a flow for the client type.
- Send the user to the authorization server with state and an authorization-code PKCE challenge.
- Validate the returned state, then exchange the code using the verifier over TLS.
- Validate an ID token only for the client and use an access token only at its intended resource server.
- Constrain scope, audience, lifetime, refresh, revocation, and storage; apply current OAuth security guidance.
Concrete example#
Sign in and read a calendar are separate grants
OpenID Connect lets the client establish the user's identity using the ID token. An audience- and scope-constrained access token authorizes the calendar API. The API does not accept the ID token as its access credential.
Architecture consequence: Model identity and delegated API access separately, even when one authorization response carries artifacts for both.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Authorization code with PKCE | A browser or native client delegates user access. | Redirect, state, verifier, token storage, and refresh handling must be correct. |
| Short access tokens | Limit replay duration and stale authorization. | Refresh paths and authorization-server availability matter more. |
| Broad scopes | Avoid; request only product-required access. | Overbroad grants increase breach impact and user distrust. |
Failure diagnosis#
- Failure
- A client accepts an authorization response without correlating state or redirect context.
- Impact
- Login CSRF, response injection, or authorization-code substitution can bind the wrong authorization result.
- Detection
- Flow tests accept missing, mismatched, replayed, or cross-client state.
- Mitigation
- Use exact redirect matching, one-time state, PKCE, issuer/client checks, and the current OAuth security profile.
- Trade-off
- More correlation state and rejection paths complicate client implementation.
Checklist exercise#
Work the scenario before revealing your answer
- Label every actor and artifact in the diagram and state who may consume it.
- Write validation checks for state, code exchange, access token, and ID token.
- Reduce requested scope and token lifetime for a concrete product action.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- What is OAuth delegating?
- What does OpenID Connect add?
- Why can the resource server reject a correctly signed token?
- How are refresh-token theft and redirect attacks contained?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.