Software Systems Atlas

English

中文

English

中文

Theme

3.2 OAuth 2.0 and OIDC: Delegation of Authorization Is Not a Shortcut to Login ​

OAuth 2.0 enables resource owners to delegate limited API permissions to clients without sharing their passwords with them. OpenID Connect (OIDC) builds upon OAuth 2.0 by adding identity assertion semantics. Using an access token as proof of login or treating an ID token as a valid API credential crosses protocol boundaries.

Get Clear on Four Roles ​

text
Resource Owner: typically the user
Client: an application that is authorized to request permissions
Authorization Server: authenticates the user and issues tokens
Resource Server: holds the protected API

A Client ID is a public identifier, not a password. Browser-based SPAs and native applications cannot reliably secure static client secrets, so they are classified as public clients. Backend services can only act as confidential clients if they can securely protect their credentials within a controlled environment.

Authorization Code + PKCE is the Default Interaction Flow ​

Simplified flow:

text
client generates code_verifier
        └─ SHA-256 → code_challenge

browser → authorization endpoint
          client_id, exact redirect_uri, state,
          code_challenge, method=S256

authorization server → redirect with one-time code + state

client → token endpoint
         code + original code_verifier

PKCE makes it impossible for an attacker who intercepts the authorization code to obtain a token, because they lack the verifier. The verifier must be regenerated for each request and securely stored within the client's context at the time of initiation, never hardcoded or reduced to a weak authentication method.

state binds the initial request to the callback, preventing login CSRF and response tampering; OIDC's nonce binds the ID token to the authentication request, helping prevent replay attacks. These serve different purposes and should not be removed simply because PKCE is in place.

The redirect URI must be registered and matched exactly. Wildcards, open redirects, and loose string-prefix comparisons can route the code or token to attacker-controlled locations.

OAuth 2.1 Is Still Not a Published RFC ​

As of the professional review conducted for this volume, OAuth 2.1 remains an IETF Internet-Draft. While it consolidates modern practices such as Authorization Code with PKCE and removes outdated flows like implicit and resource owner password credentials, it cannot be treated as a final standard.

Production security baselines should be based on published RFCs such as RFC 9700 (OAuth 2.0 Security Best Current Practice): avoid using the implicit grant or Resource Owner Password Credentials grant, prevent authorization code injection and token replay attacks, and strictly limit token permissions.

Token Type Determines Validation Location ​

An access token is an authorization credential issued to a Resource Server and can be either an opaque random value or a JWT. The client should not rely on internal fields of the token to infer user login status.

An ID token represents the authentication result of an OIDC client, with its target audience set to the client. Validation must include at least the following:

  • Determine the issuer from a trusted configuration, not by trusting the token’s self-reported issuer address;
  • Allow only expected signing algorithms, verified against the issuer’s trusted public key set;
  • Validate iss, aud, and optionally azp;
  • Validate exp, iat, and account for reasonable clock skew;
  • Verify nonce against the corresponding request;
  • Perform business-specific checks on auth_time, acr, and similar claims to ensure data integrity.

When validating an access token, the Resource Server focuses on the issuer, its own audience, scope or authorization details, expiration time, revocation policies, and sender constraints. It should not equate a "valid JWT signature" with "permission to access any resource."

Refresh Tokens Are High-Value Long-Lived Credentials ​

If a refresh token is exposed in browsers or mobile apps, it could continue to generate new access tokens indefinitely. RFC 9700 mandates that public clients use refresh token rotation or sender-constrained tokens and implement detection of replayed old tokens.

Access tokens should follow the principles of minimal audience, minimal scope, and short validity periods. High-value systems can use mTLS or DPoP to bind access tokens to the sender's cryptographic key, reducing the usability of copied bearer tokens, though this still does not mitigate the risk of a fully compromised endpoint.

Frontend applications should avoid storing long-lived tokens in any script-readable location, such as localStorage. For traditional web applications, a Backend-for-Frontend (BFF) can keep OAuth tokens on the backend and expose only the minimal browser session state via a protected session cookie. The choice between approaches depends on the overall architecture; treating a BFF as a universal solution risks overlooking critical concerns like CSRF, session fixation, and backend lateral privilege escalation.

OIDC Discovery Also Requires a Trust Anchor ​

Discovery enables automated key discovery and rotation via JWKS, but the URL must originate from a pre-configured issuer or be validated through a strict discovery process. It is not permissible to directly make network requests to an arbitrary token's iss, as this could lead to SSRF attacks, key confusion, or malicious issuer takeover.

Key rotation must allow for a brief overlap between old and new signing keys, and must restrict refreshes for unknown kid. An attacker could generate a large volume of random kid, and we must not allow each failure to trigger an unbounded external JWKS request.

Process Validation ​

  • Use Authorization Code + PKCE (S256) instead of implicit or ROPC?
  • Is the Redirect URI exactly registered, with no open redirect vulnerabilities?
  • Are state, OIDC nonce, and PKCE verifier values generated and validated separately?
  • Are access tokens, ID tokens, and refresh tokens isolated by audience and intended use?
  • Are the trusted issuer, algorithm, and audience fixed and explicitly defined?
  • Are tokens scoped minimally, time-limited, revocable, or replay-detectable?
  • Can browser scripts access long-lived credentials?
  • Does the API continue to enforce resource-level authorization beyond token validity?

The next lesson will specifically address the final question: after authentication, how should the system determine which specific resources a principal is authorized to access.

References ​

Built with VitePress | Software Systems Atlas

Copyright 2026 Steven Yang