auditing-device-code-and-pkce-flowslisted

# Auditing proof-key and device-code grants: when a code becomes a token without proof The proof-key exchange and the device-authorization grant both exist to close one gap: a authorization code, on its own, can be intercepted, and a short user code can be guessed. Each grant adds a proof that binds the token request to the party that actually started the flow, a verifier that only the real client knows, or a device code that only the real device holds. The server side is where that proof is enforced, and where it is quietly not. When the token endpoint issues without checking the verifier, honors a downgraded challenge, or hands tokens for a device code it never bound to a client, an intercepted or guessed code becomes a live token. You find these by reading the issuance path and asking what proof it demands before it mints a token. ## When to use - The code implements or wraps a token endpoint that redeems an authorization code, or a device-authorization grant. - A public client (one that cannot hold a secret) relies on the proof key as its protection against code interception. - You want to know whether a captured code, a downgraded challenge, or a guessed user code yields a token. ## Scope check Exercise token and device-authorization endpoints only on systems you own or are authorized to assess, with test clients and test accounts. A confirmed issuance bypass is an authentication bypass, so treat it as account-takeover-grade and coordinate. If you can't name the aut