OAuth Misconfiguration: Defensive Review

OAuth misconfiguration almost always concentrates in one parameter: redirect_uri. If the authorization server fails to validate it with an exact match against a per-client allowlist, an attacker can route a victim’s authorization code or token to a server they control and take over the account — often without ever knowing the client secret. A defensive OAuth review is mostly a hunt for loose redirect_uri validation, missing PKCE, and unvalidated state. This guide ships the review checklist plus detection for off-allowlist redirects and token anomalies.

Loose redirect handling underlies real breaches — Salt Labs’ Booking.com/Kayak findings and the 2025 Salesloft–Drift token abuse both trace to OAuth implementation gaps. The standard to align to is RFC 9700, the January 2025 OAuth 2.0 Security Best Current Practice. The flow maps to MITRE ATT&CK T1528 — Steal Application Access Token, T1550.001, and T1078.

What is an OAuth misconfiguration?

An OAuth misconfiguration is a gap in how an authorization server or client implements the OAuth flow that lets an attacker obtain a code, token, or account access they should not. The flow itself is sound; the failures are in validation — which redirect_uri values are accepted, whether state and PKCE are enforced, and how tokens are scoped and stored. Because OAuth tokens are identity, a misconfiguration here is an account takeover, much like a JWT misconfiguration.

The redirect_uri is the crown jewel: it is where the server sends the code or token after login. Validate it loosely and you hand the attacker a way to redirect that secret to themselves.

What are the common OAuth misconfigurations?

The unifying lesson: OAuth security is strict validation plus least privilege, and the detectable signals are off-allowlist redirects at request time and anomalous token use after issuance.

How to detect OAuth misconfiguration abuse

Two signals matter: an authorize request that names a redirect_uri outside the client’s allowlist, and a token used from somewhere it shouldn’t be.

Off-allowlist redirect_uri at the authorize endpoint

If you log authorize requests with the requested redirect_uri and the client’s registered allowlist, any mismatch is an attack or a broken integration.

title: OAuth Authorize Request With an Off-Allowlist redirect_uri
id: 8a1f4c92-darkpwn-illustrative
status: experimental
logsource:
  product: application
  service: oauth
detection:
  selection:
    endpoint|contains: '/authorize'
  suspect:
    redirect_uri|contains: ['@', '%2f', '%2F', '/../', 'localhost', '..']
  mismatch:
    redirect_uri_allowlisted: 'false'
  condition: selection and (suspect or mismatch)
falsepositives:
  - Newly registered legitimate callback URLs (update the allowlist, then this clears)
level: high

Token used from a new network shortly after issuance

Stolen tokens generate the same API traffic as legitimate ones, so the signal is behavioral — a token issued to one network appearing on another minutes later.

index=oauth (event=token_issued OR event=token_used)
| transaction token_id maxspan=15m
| eval issue_net=mvindex(src_subnet,0), use_net=mvindex(src_subnet,-1)
| where issue_net!=use_net
| table _time, client_id, token_id, issue_net, use_net, scope

How to run an OAuth defensive review

Audit each client and the authorization server:

1. redirect_uri: confirm exact-match validation against a per-client allowlist — no wildcards, no regex, no path-prefix matching. Test bypass payloads (@evil.com, app.com.evil.com, %2f, /../).
2. PKCE: confirm it is required for all clients, not just public ones.
3. state: confirm it is generated, bound to the session, and validated on return.
4. Flow: confirm the implicit flow is disabled; use authorization code + PKCE.
5. Token exchange: confirm redirect_uri is re-validated at the code-exchange step.
6. Config hygiene: flag wildcard/localhost redirects, unnecessary pre-consent, and over-broad default scopes.

How to prevent OAuth misconfiguration

• Scope least privilege — request and grant only the scopes the client needs.
• Store tokens safely — prefer HttpOnly cookies over local storage; implement revocation.
• For mobile, use platform link verification (Android App Links, iOS Associated Domains) instead of bare custom schemes.

Common OAuth detection mistakes

• Not logging authorize requests. Off-allowlist redirects go unseen.
• Content-based token detection. Stolen and legitimate tokens look identical — you need behavioral baselines.
• Regex/wildcard redirect validation. The most common bypass source; use exact match.
• Treating it as a one-time review. Misconfigurations sit for months; review configs continuously.

OAuth misconfiguration checklist

1. Enforce exact-match redirect_uri validation (scheme, host, port, path) per client.
2. Ban wildcard and regex redirect matching; require HTTPS.
3. Require PKCE for all clients; validate state; disable the implicit flow.
4. Re-validate redirect_uri at the token-exchange step.
5. Apply least-privilege scopes; remove unnecessary pre-consent grants.
6. Log authorize requests; alert on off-allowlist or open-redirect redirect_uri.
7. Baseline token use (network/geo/scope) and alert on deviation after issuance.
8. Store tokens in HttpOnly cookies; support revocation; align to RFC 9700.

The takeaway

An OAuth misconfiguration review is mostly a redirect_uri review: exact-match validation, PKCE everywhere, validated state, and re-validation at token exchange, all aligned to RFC 9700. Detect off-allowlist redirects at request time and anomalous token use after issuance. Pair this with JWT misconfiguration detection and GraphQL authorization for full API-security coverage, harden the human side with YubiKey deployment and phishing detection beyond DMARC, or browse the Detection Engineering pillar.