skip to content

Which `response_type` should a browser-only client and a server-side client each ask for, and what differs downstream?

level: middleimportance: must knowfreq 64%

answer

  1. one parameter, one decision
  2. the shape shows up later, not here
  3. both send the same value
  4. the difference is at the token endpoint
  5. confidential authenticates, public identifies

basics

~20 s

Both ask for response_type=code. The response type is the same because neither wants identity artefacts delivered through the browser; what differs is the token-endpoint leg, where the server-side client can authenticate itself and the browser-only client cannot.

solid answer

~40 s

Both send `response_type=code`. That surprises candidates who expect the browser-only client to need something different, but `response_type` answers only one question — *which artefacts come back on the redirect* — and the answer is the same for both: just a code, because neither client wants an `id_token` or an access token delivered through a user agent. What differs is the next leg. The server-side client is a confidential client: it can hold credentials and authenticate itself at the `token_endpoint`, which is the property the specification's flow comparison records as the client being able to be authenticated. The browser-only client cannot hold credentials and therefore only identifies itself with its `client_id`. Same `response_type`, different client shape, different token-endpoint exchange.

code

http · 5 lines
http
GET /authorize?response_type=code
  &scope=openid
  &client_id=roster-8812
  &redirect_uri=https%3A%2F%2Froster.pilotage.example%2Fcb HTTP/1.1
Host: idp.pilotage.example

go deeper

for a junior

Remember the headline: both ask for the same thing. The response type is a statement about what comes back on the redirect, not about what kind of software is asking, so do not expect two different values here.

for a middle

Explain the split cleanly — response_type sets the artefacts and the channel, the client's shape sets what happens at the token endpoint — and name the flow-comparison property about the client being able to be authenticated.

for a senior

Demonstrate that you check response_types_supported at bootstrap and that you know provider policy can be narrower than the published metadata. Be ready to say what replaces client authentication for a public client without wandering into that mechanism's own detail.

for a principal

The judgment call is whether to allow more than one response type across an estate at all. Permitting several buys integration flexibility for clients you do not own and costs you a review question on every new registration.

## The question behind the question An interviewer asking this is not testing whether you can recite six `response_type` values. They are testing whether you have separated two decisions that beginners fuse into one: 1. **Which artefacts come back, and on which channel** — that is `response_type`, and nothing else sets it. 2. **How the client proves who it is when it collects them** — that is the client's own shape, settled on the token-endpoint leg. Candidates who have only copied an integration answer the first question with a fact about the second, and it shows immediately. ## What both clients ask for Take two pieces of software signing users in through one provider: a handover board rendered in a browser, and a rostering application that runs on a server and renders pages from there. Both send `response_type=code`. Both therefore get exactly one artefact back on the redirect — an authorization code — and both collect the `id_token` and the access token from the `token_endpoint` on a separate leg. The board is not offered a shortcut because it is browser-resident; it is precisely the client for which delivering an `id_token` through the user agent would be worst, because the user agent is the part of the system it does not control. ## What actually differs The difference lives entirely in the token-endpoint exchange: - The **rostering application** is a confidential client. It runs somewhere that can keep a credential away from end users, so the provider can require it to authenticate itself before it will exchange a code. That is a real security property: an attacker who somehow obtained a code still cannot redeem it. - The **handover board** is a public client. Everything it ships is readable by whoever loads it, so there is no credential it can keep. It identifies itself with `client_id` and nothing more, and the provider must treat the redemption as unauthenticated. What replaces that missing authentication for a public client is a separate mechanism with its own request parameters, and it is deliberately not part of `response_type`. ## The specification's own comparison The three flows are compared on properties, not on client types. These are the rows that bear on this decision: | Property | Authorization Code Flow | Implicit Flow | Hybrid Flow | |---|---|---|---| | All tokens returned from the token endpoint | yes | no | no | | Tokens not revealed to the user agent | yes | no | no | | Client can be authenticated | yes | no | yes | | Completes in one round trip | no | yes | no | Read the third row carefully. "Client can be authenticated" is a property of the **flow**, meaning the flow has a leg on which authentication is possible at all. Whether a given client uses it depends on whether that client can hold a credential. The code flow permits it; the board simply has nothing to present. ## Why the older answer was different For several years the received answer was that a browser-resident client should ask for `id_token token`, on the reasoning that it had no secret and so could not use the token endpoint anyway. That reasoning conflates the two decisions above: not being able to authenticate at the token endpoint is not a reason to avoid the token endpoint. The specification's response types have not changed, but the advice about which one a browser-resident client should ask for has, and an answer that still recommends returning tokens through the user agent for that reason is dated. ## Reading what the provider will run Before committing to a value, read it off the provider's configuration document: - `response_types_supported` lists the `response_type` values it will honour. A provider may publish several and still have policy that refuses one for a particular client. - `response_modes_supported` lists the encodings it offers for the redirect. That is a separate axis from `response_type` — it changes how the artefacts are packaged onto the redirect, never which ones there are. A client that asserts both at startup fails on a deployment mistake rather than on a user's first sign-in attempt. ## The answer in one line Same `response_type` for both — `code`. Different client shape, and therefore a different token-endpoint exchange. If your answer makes `response_type` depend on whether the client can keep a credential, you have attached the wrong decision to the wrong parameter.

  • Why does the flow comparison say the client 'can be' authenticated rather than 'is' authenticated?
    Because it is a property of the flow, not of the client. The Authorization Code Flow has a back-channel leg on which authentication is possible; the Implicit Flow has none, so the question cannot even arise there. Whether a particular client uses that possibility depends on whether it can hold a credential away from its users.
  • A provider's `response_types_supported` lists `code` and `id_token token`, but the request for `code` is refused. What happened?
    The metadata states what the provider implements, not what it permits for your registration. Per-client policy can allow a narrower set than the document advertises, and a client registered as browser-resident may be restricted regardless. Read the metadata as a capability ceiling, then confirm the registration's own allowed values with the provider.
  • If both clients send the same `response_type`, does the provider treat the two authorization requests identically?
    At the authorization endpoint, largely yes — it resolves the `client_id`, checks the redirect URI against what that client registered, authenticates the user and returns a code. The divergence is at redemption: the provider requires the confidential client to authenticate before it exchanges the code, and accepts the public client's redemption without that step.

saying these in an interview costs you the question

  • Says a browser-only client must ask for a response type returning tokens directly.
  • Treats response_type as the parameter that decides how a client authenticates.
  • Claims a server-side client needs a different response_type from a browser one.
  • Believes a browser-resident client can keep a client secret if it is obfuscated.
  • Thinks response_types_supported lists client shapes rather than flows a provider runs.