OAuth PKCE, DPoP, and mix-up
Modern OAuth fails when the token endpoint does not require what the metadata advertises. PKCE (RFC 7636) and DPoP (RFC 9449) only help if a token is refused without the proof. Mix-up is a client that sends a code to the wrong token endpoint.
Tags: oauth, oidc, dpop, pkce
Level: advanced
Method
Read the metadata
Open the authorization-server or OpenID configuration. Note grant types, code challenge methods, and whether DPoP signing algorithms are advertised. The document is the claim. The token endpoint is the check.
Tools: browser
Complete one normal login
Use an account you own. Record whether a code challenge was sent and whether the token request included the verifier. Do not strip proofs on the first pass.
Tools: Burp Suite
See what is actually required
On a second login you own, note which of code_verifier and a DPoP proof the token endpoint rejects when they are absent. A metadata flag that the server ignores is the note.
Tools: Burp Suite
redirect_uri match
Record the registered redirect value. Exact match is the safe rule. Only use a redirect target the program allows and you control.
Tools: Burp Suite
Mix-up
If the client talks to more than one issuer, check that the authorization response is bound to the issuer the client thinks it asked. A code accepted by the wrong token endpoint is the mix-up.
Tools: Burp Suite
Public versus confidential clients
A public client with no PKCE, or a confidential client that receives a token with no client authentication, is the design note. Do not guess the client secret.
Tools: browser
Field notes
- The older OAuth playbook still covers redirect and state. This page is PKCE, DPoP, and mix-up.
- DPoP binds the token to a key the client holds. A bearer token issued beside a DPoP advertisement is the downgrade.
- PAR and JAR matter only if the server says it requires them and then accepts a plain authorize request.