What you’ll be able to do
- Name what may ride a modern authorization-code front-channel redirect (a short-lived authorization code) versus where the access token appears (filled at the Client after a back-channel exchange).
- Explain that putting the access token on the front-channel redirect as the happy path is the old Implicit habit, not modern practice.
- Separate OAuth delegated access from human login proof, and point to the assertions lesson for an authentication assertion / OIDC ID Token.
Cafe Wi-Fi watched the Harbor Mail redirect
Harbor Mail shows “Sign in with Riverstone.” Sam clicks it on cafe Wi-Fi. Map the four roles on this grant: resource owner is Sam, client is Harbor Mail, authorization server is Riverstone. Cafe Wi-Fi and other observers can see the front-channel redirects. What may ride that rail is a short-lived authorization code. The access token fills at Harbor Mail after a back-channel exchange with Riverstone. That token still does not prove which human was present. Open Code on the front. Token on the back. for the picture and the check.
Code on the front. Token on the back.
In the authorization code grant, the client sends the browser to the authorization server on the front channel. Observers on that path can see those redirects. What comes back on that front channel is a short-lived authorization code, not the long-lived access token that will call the resource API.
The client then exchanges that code with the authorization server on a back channel the front-channel redirect does not carry. The access token fills at the Client. Modern practice prefers this shape for a person in a browser. Putting the access token on the front-channel redirect as the happy path is the old Implicit habit. The OAuth 2.1 draft removes Implicit and Resource Owner Password Credentials, and RFC 9700 says those grants must not be used.
An access token still delegates a limited action. It does not prove which human was present. That identity-layer claim belongs with an authentication assertion, which the assertions lesson practices. The ticket-path lesson keeps four roles and what a ticket can open. This figure only separates front-channel code from back-channel token. Name the front-channel code and the back-channel token. Skip a field-by-field protocol walk. Watch which stub rides the front-channel rail, where the Client token well fills, and what fails on Token-on-front or Wrong redirect.
CODE VS TOKEN
Code on the front. Token on the back.
Follow the authorization code. Find the access token at the Client.
Sam maps to Resource owner. Harbor Mail maps to Client. Riverstone maps to AS.
Which path explains this picture?
Token on front: Access-token stub on the front rail is a fault. Not modern practice. Auth code flow: Auth code traveled the front channel. Access token filled at Client after back-channel exchange.
Which path explains this picture?
Wrong redirect: Code refuses at the wrong client. Client token well does not settle as a grant.
Chapter 1 of 5
Read all chapters
Plays once when the picture comes into view, then stops. Play resumes; Replay starts over. Scrub or choose a chapter to pause and inspect. Leaving the picture or hiding the tab pauses playback. Reduced motion shows still chapters with no travel.
Auth code flow
- Sam maps to Resource owner. Harbor Mail maps to Client. Riverstone maps to AS.Client, AS, and Resource owner are named. Front rail idle. Client access-token well empty. Auth code quiet.
- Harbor Mail sends Sam to Riverstone. Cafe can see a front-channel redirect.Client sends the browser to the AS on the front channel. Access token still absent.
- Cafe saw a code stub. Harbor Mail token well stays empty.Short-lived authorization code returns on the front channel. Access token still absent at Client.
- Harbor Mail fills its token well after the back-channel exchange.Client exchanges the code on the back channel. Access-token well fills at Client.
- Sam’s button still is not human login proof. Code on the front. Token on the back.Code on the front. Token on the back. OAuth delegates access. It does not prove which human was present.
Token on front
- Sam maps to Resource owner. Harbor Mail maps to Client. Riverstone maps to AS.Client, AS, and Resource owner are named. Front rail idle. Client access-token well empty. Auth code quiet.
- Harbor Mail sends Sam to Riverstone. Cafe can see a front-channel redirect.Client sends the browser to the AS on the front channel. Access token still absent.
- Token on front is the anti-path. An access token rides the cafe-visible redirect.Access-token stub on the front rail is a fault. The observer mark is hot. The Client token well is cracked and unfilled. Not modern practice.
- Token on front is the anti-path. An access token rides the cafe-visible redirect.Access-token stub on the front rail is a fault. The observer mark is hot. The Client token well is cracked and unfilled. Not modern practice.
- Token on front is the anti-path. An access token rides the cafe-visible redirect.Access-token stub on the front rail is a fault. The observer mark is hot. The Client token well is cracked and unfilled. Not modern practice.
Wrong redirect
- Sam maps to Resource owner. Harbor Mail maps to Client. Riverstone maps to AS.Client, AS, and Resource owner are named. Front rail idle. Client access-token well empty. Auth code quiet.
- Harbor Mail sends Sam to Riverstone. Cafe can see a front-channel redirect.Client sends the browser to the AS on the front channel. Access token still absent.
- Wrong redirect. The authorization code refuses at the wrong door. Harbor Mail receives no access token.Code refuses at the wrong client. Client token well does not settle as a grant. There is no back-channel exchange or access-token fill.
- Wrong redirect. The authorization code refuses at the wrong door. Harbor Mail receives no access token.Code refuses at the wrong client. Client token well does not settle as a grant. There is no back-channel exchange or access-token fill.
- Wrong redirect. The authorization code refuses at the wrong door. Harbor Mail receives no access token.Code refuses at the wrong client. Client token well does not settle as a grant. There is no back-channel exchange or access-token fill.
Read this as a table
Sam maps to Resource owner, Harbor Mail to Client, and Riverstone to AS. Authorization code travels on the front channel. A back-channel exchange fills the access token at Client. Token on front is a fault; Wrong redirect refuses. OAuth delegates access. Identity needs an authentication assertion.
| Path / chapter | What changes |
|---|---|
| Place | Client, AS, and Resource owner are named. Front rail idle. Client access-token well empty. Auth code quiet. |
| Redirect | Client sends the browser to the AS on the front channel. Access token still absent. |
| Code back | Short-lived authorization code returns on the front channel. Access token still absent at Client. |
| Exchange | Client exchanges the code on the back channel. Access-token well fills at Client. |
| Settle | Code on the front. Token on the back. OAuth delegates access. It does not prove which human was present. |
| Token on front | Access-token stub on the front rail is a fault. The observer mark is hot. The Client token well is cracked and unfilled. Not modern practice. |
| Wrong redirect | Code refuses at the wrong client. Client token well does not settle as a grant. There is no back-channel exchange or access-token fill. |
Scene checked 2026-09-28.
CHECK THE PICTURE
In a modern authorization code flow, what may ride the front-channel redirect, and where does the access token appear?
OAuth is not human login proof
An access token is delegated access attributes. It authorizes a limited action at a resource server. It is not proof that a particular human sits at the keyboard. OpenID Connect is the identity layer people add when they need that proof.
The assertions lesson practices authentication assertion and OIDC ID Token checks. The ticket-path lesson keeps four roles, Audience, Replay, and IdP trust. The OAuth glossary is the short “token is not an identity card” card.
Beside this lesson
Four roles and the ticket path live on Who holds the ticket, and what does it open? Public values versus a locally derived session secret live on Public values travel. The session secret does not. Reachability before a protected conversation lives on Three packets. Then ESTABLISHED.
Come back here when someone treats a front-channel redirect as the place the access token belongs, or treats a browser “Sign in” button as finished human proof. Code on the front. Token on the back. Permission and identity stay with separate checks.
CHECK YOUR JUDGMENT