Skip to content

docs(oauth): clarify code-injection ATO is code-grant-specific and PKCE's role - #18

Merged
rcha0s merged 1 commit into
mainfrom
docs/oauth-code-injection-pkce-clarify
Sep 9, 2026
Merged

rcha0s merged 1 commit into
mainfrom
docs/oauth-code-injection-pkce-clarify

Conversation

@rcha0s

@rcha0s rcha0s commented Sep 1, 2026

Copy link
Copy Markdown
Owner

Summary

  • Attack technique 4 in 14-oauth-oidc.md ("Leaking codes/tokens through a lax AS, the classic ATO") didn't state which grant type it applies to, or what actually determines whether the replay succeeds once a code has leaked.
  • Clarifies it's code-grant-specific — implicit has no redeemable artifact to replay; the token itself is the leaked thing, so implicit is strictly worse there, not exempt from this class.
  • Clarifies the replay's actual precondition: it succeeds unconditionally against a confidential client (secret already lives server-side), but is blocked against a correctly PKCE-bound public client, since the attacker's browser won't hold the matching code_verifier generated by whichever browser called /authorize.
  • Ties this back to why RFC 9700 recommends PKCE for confidential clients too, not just public ones: PKCE is the independent fix for the replay, redirect_uri re-validation at /token is the fix for the leak — an AS needs both.

Test plan

  • python -m pytest tests/ — 11/11 passed.
  • Prose-only change, no mermaid/table/link changes; existing citations (ref1 RFC 9700, ref9 RFC 7636) reused, no new sources needed.

https://claude.ai/code/session_011f1KhQCYiUUPFKco7pguLC

…w PKCE affects it

Attack technique 4 (leaking codes/tokens through a lax AS) didn't state
which grant type it applies to, or how PKCE changes the outcome once a
code has leaked -- both real gaps an interviewer would probe.

Clarifies: the attack is code-grant-specific (implicit leaks the token
itself, no replay step needed, so it's not exempt, just a more direct
version); and that the replay succeeds unconditionally against a
confidential client (secret lives server-side) but is blocked against a
correctly PKCE-bound public client, since the attacker's browser won't
hold the matching code_verifier. Ties this back to why RFC 9700
recommends PKCE for confidential clients too, not just public ones --
it's the independent fix for the replay, where redirect_uri
re-validation at /token is the fix for the leak.
@rcha0s
rcha0s merged commit 7f1f468 into main Sep 9, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant