auth-session-patternslisted

<!-- last-verified: 2026-07 --> # Auth & session patterns **`auth` / `token` / `secret` is a named `forge-security` dispatch trigger** (`docs/conventions.md`, "Verification economics"). Any diff that touches authentication, session storage, or credential/token handling pulls `forge-security` into review regardless of task tier — this skill builds the change correctly, it does not substitute for that review. ## 1. OAuth / OIDC flow shape Authorization Code + PKCE is the baseline flow for both web and native/mobile clients in 2026 — the implicit flow is deprecated (OAuth 2.1 drops it entirely). PKCE closes the authorization-code-interception gap for public clients (SPAs, mobile apps) that can't hold a client secret. - **Server-rendered / full-stack app**: authorization code exchange happens on the server, using a confidential client secret. The browser never sees the code-for-token exchange. - **SPA / mobile (public client)**: no client secret exists to protect — PKCE (code_verifier/code_challenge) is mandatory, not optional-hardening. - **OIDC vs plain OAuth**: OAuth authenticates *access* (what you can call); OIDC layers an identity assertion (the `id_token`, a signed JWT) on top for *who the user is*. If the app needs "who is this user" (not just "can this client call this API"), it needs OIDC's `id_token` — validate its signature, `iss`, `aud`, and `exp`, don't just decode and trust it. - Validate `state` on the callback (CSRF on the auth flow itself) and