Which `response_type` delivery property matters when a sign-in lands in a browser on a screen a whole crew room can read?

seniorshould knowfreq 44%

answer

which leg carries what
the address bar is an audience
five values of six overshare
only a handle belongs on the redirect
encoding is a separate parameter

basics

~20 s

Whether the response type returns identity artefacts from the authorization endpoint. Any value carrying id_token or an access token there delivers it inside the redirect URI, on a display several people can read; response_type=code leaves only a single-use handle on that channel.

solid answer

~50 s

The property is where the artefacts are delivered, which is exactly what response_type decides. Values that return an id_token or an access token from the authorization_endpoint — id_token, id_token token, code id_token, code token, code id_token token — put that artefact inside the redirect URI itself, so it is rendered wherever that browser's address bar is rendered and is available to everything running in that user agent. On a large shared screen in a crew room, the front channel is a public display. response_type=code puts only a single-use authorization code there and delivers the tokens on the back-channel leg instead. The nuance that separates a good answer from a slogan: front-channel delivery is not insecure by definition — it is risky in proportion to who can observe that user agent, and here the answer is 'anyone standing in the room'.

The property is **where the artefacts are delivered**, which is exactly what `response_type` decides. Values that return an `id_token` or an access token from the `authorization_endpoint` — `id_token`, `id_token token`, `code id_token`, `code token`, `code id_token token` — put that artefact inside the redirect URI itself, so it is rendered wherever that browser's address bar is rendered and is available to everything running in that user agent. On a large shared screen in a crew room, the front channel is a public display. `response_type=code` puts only a single-use authorization code there and delivers the tokens on the back-channel leg instead. The nuance that separates a good answer from a slogan: front-channel delivery is not insecure by definition — it is risky in proportion to who can observe that user agent, and here the answer is 'anyone standing in the room'.

code

http · 8 lines

http

HTTP/1.1 302 Found
Location: https://board.pilotage.example/cb?code=SplxlOBeZQQYbYS6WxSbIA

HTTP/1.1 302 Found
Location: https://board.pilotage.example/cb#id_token=eyJhbGciOiJSUzI1NiJ9.eyJzdWIi...
  &access_token=SlAV32hkKG
  &token_type=Bearer
  &expires_in=3600

go deeper

for a junior

Hold on to the basic split: some response type values deliver tokens through the browser, and one delivers only a code. If the browser is somewhere other people can see, that difference is the whole point.

for a middle

Explain which of the six values put an id_token or an access token on the redirect, and be able to say why a code on the same channel is a much smaller exposure than a bearer credential.

for a senior

Give the conditional answer, not the slogan: front-channel delivery is risky in proportion to who can observe the user agent. Then separate response_mode from response_type cleanly, and say what the shared screen still costs after sign-in.

for a principal

The wider call is a deployment policy: which classes of surface in an estate are permitted to receive artefacts on the front channel at all. Writing that rule once is cheaper than adjudicating it per integration.

The property `response_type` really controls

response_type decides two things at once, and the second is the one that matters here: which artefacts come back, and on which channel they arrive. The two are not separable, because the value that names an artefact also determines the leg it is delivered on.

There are only two legs:

the front channel — a redirect carried by the user agent, visible in its address bar, held in its memory and reachable by anything else executing in it;
the back channel — a direct request the client makes itself, which the user agent never participates in.

Which values put identity artefacts on the front channel

`response_type`	Delivered on the redirect	Delivered on the back-channel leg
`code`	an authorization code	`id_token` and access token
`id_token`	`id_token`	nothing
`id_token token`	`id_token` and access token	nothing
`code id_token`	code and `id_token`	access token, second `id_token`
`code token`	code and access token	`id_token`
`code id_token token`	code, `id_token`, access token	second set on exchange

Five of the six values put something more than a code on the front channel. Only code keeps both identity artefacts entirely off it.

Why a shared screen changes the arithmetic

The usual reasoning about front-channel delivery assumes one user, one device, one pair of eyes. A handover board mounted on a wall in a shared crew room breaks all three assumptions at once:

the address bar is rendered for the room, so a value in the redirect URI is on display to everyone in it, for as long as the page sits there;
the artefact is present in a user agent nobody is individually accountable for, which is the opposite of the personal-device assumption the front channel is usually reasoned about under;
an access token delivered that way is a credential a resource server will accept from whoever presents it, for as long as it lives — so the exposure is not theoretical, it is the whole point of a bearer credential.

An id_token on the same screen is a different kind of loss — it is an authentication statement addressed to the client, not an API credential — but it is still a signed document about a named person, on a wall.

Front channel is not a synonym for insecure

This is where candidates overshoot. The front channel is a legitimate, specified delivery mechanism; the authorization request itself travels on it and always will. The specification's comparison does not say front-channel delivery is unsafe — it records a property, tokens not revealed to the user agent, and leaves the consequence to the deployment.

The honest formulation is conditional: front-channel delivery exposes an artefact to the user agent and to whoever can observe it, and the cost of that depends entirely on who that is. On a personal device it is a manageable exposure. On a wall-mounted display in a shared room it is publication.

`response_mode` is a different knob

A related parameter, response_mode, controls how the artefacts a response_type returns are encoded onto the redirect. It is worth naming precisely because it is so often confused with response_type:

response_type decides which artefacts come back and on which leg;
response_mode decides only how those same artefacts are packaged onto the redirect;
a provider advertises what it will run in response_types_supported and response_modes_supported.

Changing the encoding changes where in the redirect a value sits and which components of the system see it — it does not remove an artefact from the front channel. Only choosing a different response_type does that.

What this means for the board

Ask for response_type=code, so the only thing on the shared screen is a single-use handle that is worthless without the exchange.
Treat the fact that the board's user agent is shared as a property of the deployment that outlives the sign-in, and size the resulting session accordingly.
Confirm the provider will actually run the chosen value by reading response_types_supported, rather than discovering the refusal on the first shift handover.

The general rule generalises past this room: choose the response_type by asking who can observe the user agent, and only then by what is convenient for the client.

## The property `response_type` really controls `response_type` decides two things at once, and the second is the one that matters here: **which artefacts come back**, and **on which channel they arrive**. The two are not separable, because the value that names an artefact also determines the leg it is delivered on. There are only two legs: - the **front channel** — a redirect carried by the user agent, visible in its address bar, held in its memory and reachable by anything else executing in it; - the **back channel** — a direct request the client makes itself, which the user agent never participates in. ## Which values put identity artefacts on the front channel | `response_type` | Delivered on the redirect | Delivered on the back-channel leg | |---|---|---| | `code` | an authorization code | `id_token` and access token | | `id_token` | `id_token` | nothing | | `id_token token` | `id_token` and access token | nothing | | `code id_token` | code and `id_token` | access token, second `id_token` | | `code token` | code and access token | `id_token` | | `code id_token token` | code, `id_token`, access token | second set on exchange | Five of the six values put something more than a code on the front channel. Only `code` keeps both identity artefacts entirely off it. ## Why a shared screen changes the arithmetic The usual reasoning about front-channel delivery assumes one user, one device, one pair of eyes. A handover board mounted on a wall in a shared crew room breaks all three assumptions at once: - the address bar is **rendered for the room**, so a value in the redirect URI is on display to everyone in it, for as long as the page sits there; - the artefact is present in a user agent **nobody is individually accountable for**, which is the opposite of the personal-device assumption the front channel is usually reasoned about under; - an access token delivered that way is a credential a resource server will accept from whoever presents it, for as long as it lives — so the exposure is not theoretical, it is the whole point of a bearer credential. An `id_token` on the same screen is a different kind of loss — it is an authentication statement addressed to the client, not an API credential — but it is still a signed document about a named person, on a wall. ## Front channel is not a synonym for insecure This is where candidates overshoot. The front channel is a legitimate, specified delivery mechanism; the authorization request itself travels on it and always will. The specification's comparison does not say front-channel delivery is unsafe — it records a property, *tokens not revealed to the user agent*, and leaves the consequence to the deployment. The honest formulation is conditional: front-channel delivery exposes an artefact to the user agent and to whoever can observe it, and the cost of that depends entirely on who that is. On a personal device it is a manageable exposure. On a wall-mounted display in a shared room it is publication. ## `response_mode` is a different knob A related parameter, `response_mode`, controls how the artefacts a `response_type` returns are **encoded** onto the redirect. It is worth naming precisely because it is so often confused with `response_type`: - `response_type` decides **which** artefacts come back and on which leg; - `response_mode` decides only **how those same artefacts are packaged** onto the redirect; - a provider advertises what it will run in `response_types_supported` and `response_modes_supported`. Changing the encoding changes where in the redirect a value sits and which components of the system see it — it does not remove an artefact from the front channel. Only choosing a different `response_type` does that. ## What this means for the board 1. Ask for `response_type=code`, so the only thing on the shared screen is a single-use handle that is worthless without the exchange. 2. Treat the fact that the board's user agent is shared as a property of the deployment that outlives the sign-in, and size the resulting session accordingly. 3. Confirm the provider will actually run the chosen value by reading `response_types_supported`, rather than discovering the refusal on the first shift handover. The general rule generalises past this room: choose the `response_type` by asking who can observe the user agent, and only then by what is convenient for the client.

Does switching `response_mode` remove an artefact from the front channel?
No. `response_mode` changes only how the artefacts a `response_type` returns are encoded onto the redirect; the set of artefacts is unchanged. It can move a value between parts of the redirect, and that genuinely alters which components handle it, but an access token returned by `id_token token` is still delivered through the user agent whatever the encoding.
The board is a public display, so is an `id_token` on the redirect as bad as an access token?
Not equally, though neither belongs there. An access token is a bearer credential a resource server will accept from anyone holding it until it expires. An `id_token` is an authentication statement addressed to the client; a bystander cannot spend it at an API, but it is still a signed document naming a person, readable off the screen.
Given the shared user agent, what does choosing `response_type=code` not solve?
Everything after sign-in. The code keeps tokens off the display, but the board's session then sits in a browser in a shared room, and whoever walks up next inherits it. That is a session-lifetime and re-authentication decision for the relying party, not something a response type can address.

saying these in an interview costs you the question

Says front-channel delivery is insecure everywhere, regardless of who observes it.
Thinks response_mode changes which artefacts a response_type returns.
Claims an access token in a redirect URI is harmless once the page loads.
Believes only access tokens, never ID tokens, travel on the front channel.
Assumes a provider will run any response_type value a client asks for.
Treats an ID token read off a screen as usable at a resource server.

Which `response_type` delivery property matters when a sign-in lands in a browser on a screen a whole crew room can read?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The property response_type really controls

Which values put identity artefacts on the front channel

Why a shared screen changes the arithmetic

Front channel is not a synonym for insecure

response_mode is a different knob

What this means for the board

▾common follow-ups3 questions

▾red flags6 flags

The property response_type really controls

Which values put identity artefacts on the front channel

Why a shared screen changes the arithmetic

Front channel is not a synonym for insecure

response_mode is a different knob

What this means for the board

answer

go deeper

The property `response_type` really controls

`response_mode` is a different knob

The property `response_type` really controls

`response_mode` is a different knob