Watch & compare
OAuth PKCE
Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.
Why we recommend One attempt, one verifier
Sol establishes a successful code-and-verifier exchange before showing two overlapping sign-ins, the crossed pair, and recovery with a fresh attempt. That makes it the clearest entry into this chapter’s agent-host integration problem. Astra offers larger, less crowded labels for revisiting the concurrency failure, while the baseline adds the complementary reason PKCE exists: an intercepted code is insufficient without its verifier.
Revised original · 26 sec
Code interception protection
An intercepted authorization code cannot be redeemed without its private PKCE verifier.
Read the video sequence
- 0–7s: The mobile app retains a verifier and sends its S256 challenge. The server binds a newly issued authorization code to that challenge.
- 8–15s: An interceptor gets the code but not the verifier. Its token request is rejected.
- 16–22s: The legitimate app supplies the verifier. The server checks the challenge, consumes the code and returns the access token.
About this cut
Production: Original prototype; model not recorded.
Revision: gpt-6-astra comparative review.
The mobile-app interception example complements the chapter’s agent-host concurrency example.
Browser consent, redirects, TLS and other OAuth checks are omitted. Token issuance assumes those checks pass.
The final legitimate redemption illustrates possession of the correct verifier; do not assume every server preserves a code after a rejected exchange. Start a fresh attempt when needed.
NO TOKEN describes rejection without prescribing a provider-specific missing-verifier error.
Audio analysed, not physically heard.
Alternative · Astra · 30 sec
One login, one verifier
Keep each agent-host OAuth login tied to its own verifier: crossed transaction pairs fail PKCE.
Read the video sequence
- The agent host starts login A, retains verifier A, and sends its S256 challenge. The server associates the returned code A with that challenge.
- Login B starts alongside A with a different verifier and challenge. Both transactions have their own code and verifier.
- An illustrative callback bug replaces the selected verifier in login A with verifier B. Code A and verifier B are sent together. The server derives a different challenge and rejects the exchange with invalid_grant; no token is returned.
- The host abandons the confused local attempts and starts fresh login C with its own verifier and challenge. Clearing the diagram does not represent server-side revocation.
- Code C and verifier C match the stored challenge. PKCE passes and, assuming the other OAuth checks pass too, the host receives a token. Tool permissions remain a separate check.
About this cut
Production: gpt-6-astra.
Revision: gpt-6-astra comparative review.
Illustrative concurrent-login bug; not an observed product incident or the OAuth issuer mix-up attack.
A/B/C are symbolic; hash abbreviates the full S256 transform.
Token issuance assumes other OAuth checks pass; browser consent, redirects and permission enforcement are omitted.
Screen clearing is not revocation; the repair begins a fresh authorization attempt.
Audio analyzed but not physically listened to.
Original author evidence is retained separately; final encoded evidence and independent comparison are in reviews/comparisons/oauth-pkce/. No live provider test or continuous real-time playback review was performed.
Recommended · Sol · 32 sec
One attempt, one verifier
Keep each OAuth sign-in's verifier bound to its authorization attempt: the token endpoint rejects a code paired with another attempt's verifier.
Read the video sequence
- An agent host starts sign-in A. It keeps a fresh secret called a verifier and sends an S256 challenge derived from it. The authorization server associates that challenge with code A and returns the code.
- The host sends code A and verifier A to the token endpoint. The server transforms the verifier and finds the stored challenge matches. Assuming the other OAuth checks pass, it issues a token and consumes the code.
- Two new sign-ins, B and C, overlap. Each has a separate verifier, challenge and code. Their values belong to separate authorization attempts.
- An illustrative client bug puts C's verifier into B's exchange. The server receives code B with verifier C. Its transformed value differs from B's stored challenge, so the server returns invalid_grant and issues no token.
- The host clears the failed flow and starts fresh sign-in D with its own verifier. D's challenge and code remain paired through exchange. The comparison matches and the valid request receives a token. This protects the code exchange; agent permissions still require separate access controls.
About this cut
Production: gpt-6.1-sol.
Revision: gpt-6-astra comparative review.
Illustrative concurrent sign-ins in an agent host; A–D represent full random verifier values, not literal secrets.
Consent, TLS and other OAuth validation are omitted. A matching verifier does not by itself guarantee token issuance.
PKCE does not enforce agent permissions or turn persistent prompts into access controls.
Audio was decoded and analysed for levels and activity near declared cues, with spectrogram inspection; it was not physically heard. Perceptual quality and exact audiovisual synchronization remain untested.
Original author evidence is retained separately; final encoded evidence and independent comparison are in reviews/comparisons/oauth-pkce/. No live provider test or continuous real-time playback review was performed.
These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.
What the review found
- Sol 00:01–00:09 teaches the normal exchange before B/C overlap at 00:10–00:16; Astra introduces two attempts before its first success at 00:24–00:27. Sol gives a newcomer a working model to compare with the failure.
- Astra 00:12.3–00:14.5 now retains verifier B in login A before sending the crossed pair. Sol 00:16–00:21 shows the comparable B/C substitution and returned invalid_grant, making the client mistake and server response especially explicit.
- Baseline 00:09–00:15 demonstrates code interception while the verifier remains private; it complements the alternatives’ concurrency lesson. The rejection now says NO TOKEN because an absent verifier should not be conflated with the alternatives’ supplied-but-mismatched verifier.
- At 350px, Astra’s two transaction rows at 00:07.5 and 00:14.5 are easiest to read. Sol’s four records at 00:15.5–00:20 are denser but retain the code/challenge associations; baseline’s formula at 00:02–00:03.5 is the smallest and needs the written guide.
- Sol 00:22–00:30 and Astra 00:18–00:28 recover with fresh attempts. Baseline 00:16–00:22 instead illustrates correct possession using the same code; its documented limit warns that rejected codes may need replacement. All three omit the rest of OAuth validation and cannot establish tool permissions.
- Baseline resolves by 00:20 and fades at 00:22.3–00:23.4; Astra resolves around 00:26 and Sol around 00:28. Their holds make the result readable, although Sol repeats the success mechanism and baseline leaves a longer black tail. All final first/last frames match.