OAuth Security Definition OAuth security is the set of controls that keep OAuth/OIDC authorization flows from leaking authorization codes, tokens, identity claims, or redirect trust to the wrong client or attacker-controlled destination. Why it matters OAuth is not just "login with another provider." It is a redirect-based delegation protocol involving browsers, clients, identity providers, redirect URIs, codes, tokens, scopes, and user identity claims. Small validation gaps can become account takeover or token theft. This note focuses on web app OAuth/OIDC flaws. jwt-attacks owns JWT validation details, and open-redirect owns generic redirector behavior. How it works OAuth authorization-code flow has 6 trust checks: Client identity. The client is registered and allowed to use the flow. Redirect URI. The callback exactly matches a registered destination. State. The response matches the initiating browser session. Code exchange. The authorization code is exchanged by the legitimate client. Token validation. ID/access tokens have correct issuer, audience, expiry, and signature. Account binding. The returned identity maps safely to a local account. The bug is usually treating one successful OAuth step as proof that every trust check succeeded. Techniques / patterns Attackers test: open redirect chains in registered redirect URIs weak or missing state redirect URI matching by prefix, suffix, or wildcard code leakage through referrers, logs, or third-party redirects account confusion through email claim trust scope overreach and token reuse ID token validation gaps Variants and bypasses OAuth flaws appear in 7 forms. 1. Redirect URI bypass Validation accepts attacker-controlled callback destinations. 2. Missing or weak state CSRF or login confusion becomes possible. 3. Open redirect chaining A trusted redirect URI forwards codes or tokens elsewhere. 4. Code interception Codes leak through logs, referrers, browser history, or malicious clients. 5. Token validation failure The app trusts tokens with wrong issuer, audience, expiry, or signature. 6. Account linking confusion Email or provider identity is bound to the wrong local account. 7. Scope overreach The client requests or receives broader permissions than needed. Impact Ordered roughly by severity: Account takeover. Codes, tokens, or identity claims bind to attacker control. Token theft. Redirect or validation bugs leak usable tokens. Login CSRF. Victims are logged into attacker-linked accounts. Privilege or data overreach. Broad scopes expose more than the feature needs. Identity confusion. Wrong issuer/provider/account mapping grants access. Detection and defense Ordered by effectiveness: Use exact redirect URI matching. Avoid wildcards, prefix checks, and redirect-chain endpoints. Use strong, per-request state and validate it server-side. state binds the browser session to the OAuth response. Use authorization code with PKCE for public clients. PKCE reduces code interception risk, especially for SPAs and mobile clients. Validate tokens fully. Check signature, issuer, audience, expiry, nonce where relevant, and required claims. Bind accounts using stable provider subject IDs. Do not rely only on mutable or unverified email claims. Request least-privilege scopes. Scopes should match the feature, not provider defaults. What does not work as a primary defense Wildcard redirect URIs. They make redirect trust too broad. Open redirectors as callbacks. Exact callback registration is defeated by forwarding. Email-only account binding. Emails can be unverified, changed, or provider-dependent. Decoding ID tokens without validation. Token structure is not proof of trust. Practical labs Use a local OAuth lab or owned integration. Inventory OAuth configuration client_id | redirect_uri | scopes | public/confidential | PKCE | owner Exact redirect URIs and owner fields matter. Test redirect URI strictness curl -i 'https://idp.example.test/auth?client_id=CLIENT&redirect_uri=https://app.example.test.evil.example/callback' The provider should reject non-exact destinations. Search for OAuth callbacks and state handling rg -n "redirect_uri|client_id|state|nonce|code_verifier|oauth|oidc" src config Review whether state, nonce, and token validation are enforced. Practical examples A redirect URI prefix check accepts https://app.example.test.evil.example. A registered callback is an open redirect that forwards the code. OAuth login lacks state, enabling login CSRF. ID tokens are decoded but not validated. Local accounts are linked by email without checking provider subject. Related notes open-redirect auth-flaws session-management JWT Attacks Token Lifecycle Suggested future atomic notes oauth-redirect-uri-bypass oauth-state-parameter pkce oidc-id-token-validation account-linking-flaws References Foundational: RFC 9700 OAuth 2.0 Security Best Current Practice — https://datatracker.ietf.org/doc/html/rfc9700 Testing / Lab: PortSwigger OAuth authentication — https://portswigger.net/web-security/oauth Foundational: OWASP Authentication Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html ← PreviousMFA Phishing ResistanceNext →Open Redirect Explore nearby notes Web SecurityAuthentication FlawsAuthentication flaws are weaknesses in how an application verifies identity. They include weak login logic, user enumeration, broken MFA flows, password reset... Web SecurityEvilginx and Reverse Proxy PhishingReverse-proxy phishing is an adversary-in-the-middle pattern where a phishing site proxies the real identity provider or application, relays the victim's login... Web SecurityMFA Phishing ResistanceMFA phishing resistance is the property that an authentication method cannot produce a reusable secret or valid authentication result for an impostor origin, even... Web SecurityBot Detection SignalsBot detection signals are the observable clues a web application or edge service uses to classify traffic as human, benign automation, suspicious automation, or... Web SecurityBroken Access ControlBroken access control happens when an application fails to enforce what a caller is allowed to access or do. Web SecurityBusiness Logic VulnerabilitiesBusiness logic vulnerabilities are flaws in the intended workflow, assumptions, invariants, or rule design of an application, where the system behaves as coded but...