OAuth/OIDC Implementation Security (OWASP A07:2025)
SkillSecurityDetects weak JWT validation, loose redirect_uri matching, and missing state
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the OAuth/OIDC Implementation Security (OWASP A07:2025) skill
What this skill tells your AI
The instructions your AI receives, as published by thejefflarson/soundcheck in .claude/skills/oauth-implementation/SKILL.md and read by ahel’s review.
What this checks
Prevents authentication bypasses from weak JWT validation, open redirects from loose
redirect_uri matching, and CSRF from missing state parameters. These flaws allow
account takeover and session hijacking.
Vulnerable patterns
- JWT decode call that accepts the
nonealgorithm, or accepts an attacker-supplied algorithm header — enabling algorithm-confusion bypass. redirect_urivalidated by prefix match, substring match, or regex — letting an attacker host a lookalike domain whose URL passes the check.- JWT decode that omits audience (
aud) validation — a token minted for a sibling service passes signature verification but should not be honored here. - Tokens stored in browser web storage (e.g.
localStorage) where any same-origin script can read them. - OAuth authorization request sent with no
stateparameter, or with astatethat is not bound to and verified against the initiating session.
Fix immediately
Flag the vulnerable code and explain the risk. Then suggest a fix that establishes these properties. Translate each property into the audited file's language and OAuth/JWT library — use the library's documented secure-by-default APIs rather than mirroring an example from another stack.
- JWT verification pins algorithms to an explicit allowlist that never
includes
noneand never permits switching between symmetric and asymmetric families (the classic HS256/RS256 public-key-as-HMAC attack). For broader JWT handling guidance, see theauthentication-failuresskill. - Redirect URIs match exactly against an allowlist set. Prefix matching, substring matching, and regex matching all have known bypass classes — percent-encoded tricks, userinfo smuggling, lookalike subdomains. The only safe comparison is exact string equality against a set of registered URIs.
- Every JWT decode validates
aud(audience) and required claims. A token minted for a different service of the same issuer will pass signature verification; only the audience check catches the confused-deputy case. Requireexp,iat,subat minimum. - State parameter ties the callback to the initiating session. Generate a
CSPRNG
state, store it in the session before redirect, compare it on the callback. Without this the OAuth flow is CSRF-forgeable. - Tokens live in a Secure, HttpOnly, SameSite cookie or in memory — not web storage. Browser storage is readable by any same-origin script, so one XSS compromise exfiltrates every token.
Verification
Confirm the response:
- Algorithm parameter is an explicit allowlist and never includes
none -
redirect_uriis checked with exact-match equality against an allowlist set - Audience is validated in every JWT decode call
-
stateparameter is generated, stored in session, and compared on callback - Tokens are not stored in browser web storage
References
- CWE-287 (Improper Authentication)
- CWE-601 (Open Redirect)
- CWE-346 (Origin Validation Error)
- OWASP A07:2025 Authentication Failures
Signals
- GitHub stars
- 20
- Last commit
- Jul 2026
Advanced
- Catalog kind
- skill
- Gateway key
oauth-implementation-thejefflarson- Source
- github.com/thejefflarson/soundcheck