Review an authentication flow

Authentication bugs are rarely in the cryptography. They are in the glue: a redirect URI matched by prefix, an ID token accepted without checking its audience, a refresh token that never rotates, a password reset link built from the Host header, MFA enforced on the login form but not on the API or the recovery path. Each has a well-known attack. The review must find these with a concrete path from attacker to account takeover, not list every best practice.

Review this authentication design for a web application: [DESIGN_OR_CODE]

Check each area that the material covers:

1. OAuth and OIDC: authorization code flow with PKCE for public clients (no implicit flow), state and nonce validated, exact redirect URI matching, ID token validation (signature, iss, aud, exp, allowed algorithms only), ID tokens never used as API access tokens, access tokens checked for audience, account linking only on verified email.
2. Tokens: short access-token lifetimes, refresh-token rotation with reuse detection, a revocation strategy for stateless tokens, no sensitive data in JWT claims, kid and alg handling that cannot be steered by the attacker.
3. Storage by client type: for a SPA, no long-lived tokens in localStorage (prefer a backend-for-frontend with HttpOnly cookies); for mobile, the platform keystore, the system browser rather than an embedded web view, and claimed HTTPS redirect URIs; for an API, scoped, hashed and rotatable keys.
4. Sessions and cookies: new session ID on login and privilege change, Secure, HttpOnly, SameSite and the __Host- prefix, idle and absolute timeouts, server-side invalidation on logout and password change, CSRF protection for cookie-authenticated state changes.
5. Passwords: a slow, salted hash (Argon2id, scrypt or bcrypt) with sound parameters, breached-password checks, rate limiting and credential-stuffing defences, no account enumeration through messages or timing.
6. Reset and recovery: single-use, short-lived, high-entropy tokens stored hashed; links built from configuration, not the Host header; existing sessions revoked after reset; recovery paths no weaker than login.
7. MFA: enforced server-side on every path (API, legacy endpoints, recovery), OTP attempts rate-limited, recovery codes, protection against push-fatigue, phishing-resistant options for high-value accounts.

Report a finding only when you can describe the attack path: who the attacker is, what they do step by step, and what they gain.

• Quote the line, setting or diagram step each finding is about. If a decision is not shown, ask about it under Questions instead of assuming it is wrong.
• Rank by impact: account takeover and token theft first, hardening last.
• Reference OWASP ASVS by chapter name where relevant; do not invent requirement numbers.
• Read the relevant code before making a claim about it. Do not guess what a file, function or config contains.
• If the information you need is not available, say what is missing and how to get it instead of inventing it.

Verdict

One line: ship | ship after fixes | redesign needed. Then one sentence why.

Findings

Numbered. Each: severity, location, the attack path in steps, the impact, and the fix.

Verified safe

Bullets of areas you checked and found sound.

Questions

Decisions the material does not show that change the risk.