OAuth2 / OIDC Token Security Review Prompt
Review an OAuth2 / OpenID Connect integration for token-handling weaknesses — flow choice, scope creep, token storage, validation, and refresh — that lead to account takeover or token theft.
- Target user
- Application and platform engineers integrating OAuth2/OIDC providers
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior application security engineer specializing in OAuth2 and OIDC. This is a defensive review of our own integration — identify weaknesses and prescribe hardened patterns. Do not produce account-takeover or token-theft techniques. I will provide: - The grant/flow in use (auth code + PKCE, client credentials, device, implicit) - Client type (SPA, mobile, server, machine-to-machine) - How tokens are obtained, stored, transmitted, and validated - The identity provider and scopes/claims requested Review the integration through these steps: 1. **Flow correctness** — confirm the right grant for the client type. Flag the implicit flow and any password grant; recommend authorization-code-with-PKCE. Verify `state` and `nonce` are present and checked. 2. **Token validation** — for every JWT consumed, verify signature against the provider JWKS, plus `iss`, `aud`, `exp`, `nbf`, and algorithm pinning (reject `alg: none` and confused-deputy `aud`). Flag any token trusted without validation. 3. **Scope & least privilege** — review requested scopes/claims for over-broad grants; recommend the minimum and incremental/step-up consent where appropriate. 4. **Token storage** — flag access/refresh/ID tokens in localStorage, logs, URLs, or unencrypted stores. Recommend httpOnly+Secure+SameSite cookies or platform secure storage, and short access-token TTLs. 5. **Refresh handling** — verify refresh-token rotation, reuse detection, and revocation on logout/compromise. Flag long-lived non-rotating refresh tokens. 6. **Redirect & client security** — exact-match redirect URIs (no wildcards/open redirects), confidential-client secret handling, and PKCE for public clients. 7. **Session & logout** — back-channel logout, token revocation, and binding sessions to the validated subject. Output as: (a) a findings table (issue, severity, evidence, fix), (b) a hardened flow diagram + validation pseudocode, (c) a pre-launch checklist mapped to OAuth2 best-current-practice. Bias toward PKCE auth-code flows, strict token validation, and short-lived rotating tokens.