skip to content

In OpenID Connect, an authorization request asks for offline_access and the provider ignores it — which conditions were unmet?

level: middleimportance: should knowfreq 46%

answer

  1. asking to work while nobody is watching
  2. the provider ignores rather than rejects
  3. two conditions, both mandatory
  4. one is about the response type
  5. the other is prompt=consent

basics

~20 s

A provider must ignore offline_access unless the client uses a response_type that returns an authorization code, and unless prompt=consent is present or other permitting conditions already apply. It asks for a refresh token usable without the end user.

solid answer

~50 s

`offline_access` is the scope value by which a client asks to keep acting on the end user's behalf after they have gone — in practice, to be issued a refresh token. OpenID Connect attaches two hard conditions, and a provider that sees the value without them **MUST ignore it** rather than fail the request. First, the provider must ignore `offline_access` unless the client is using a `response_type` that would result in an **authorization code** being returned. Second, `prompt=consent` **MUST** be used unless other conditions permitting offline access to the requested resources are already in place. The failure mode is quiet: the flow completes, an ID token arrives, and only the missing refresh token in the token response says anything went wrong. Note also that a refresh token is not exclusive to this scope value; `offline_access` is the explicit request for one, not the only route to one.

code

http · 7 lines
http
GET /authorize?response_type=code
  &client_id=s6BhdRkqt3
  &scope=openid%20offline_access
  &prompt=consent
  &redirect_uri=https%3A%2F%2Fsightings.example%2Fcb
  &state=af0ifjsldkj HTTP/1.1
Host: idp.example.org

go deeper

for a junior

Remember what the value asks for — the ability to keep working after the user has left — and that two conditions must be met before a provider will honour it.

for a middle

State both conditions precisely and note that the provider ignores the value rather than erroring, which is why the failure is silent. Explain that a refresh token is not exclusive to this scope value.

for a senior

Diagnose the real case: an unattended job with no credential while the interactive flow passes. Check the response type first, then prompt, then the provider's advertised support, and show why the ID token proves nothing here.

for a principal

Weigh unattended access as a standing capability rather than a request flag: which workloads genuinely need it, how the estate records that a user consented to it, and what happens to those grants when a person leaves.

## What the value is asking for Most of an OpenID Connect exchange assumes the end user is standing at the browser. `offline_access` is the scope value that says the opposite: the client wants to keep working on that user's behalf **when they are not present**. Concretely, it asks the provider for a refresh token the client can use later, unattended, without another redirect. That is a significant ask, and the specification guards it with two conditions rather than leaving it to a provider's discretion. ## The two conditions 1. **A response type that returns an authorization code.** The authorization server **MUST ignore** the `offline_access` request unless the client is using a `response_type` value that would result in an authorization code being returned. 2. **`prompt=consent`.** A `prompt` value of `consent` **MUST** be used unless other conditions for processing the request permitting offline access to the requested resources are in place. If neither condition is satisfied, the value is ignored. Note the verb: **ignored, not rejected**. The authorization request proceeds, the end user signs in, an ID token is issued, and the only visible consequence is that the token response carries no refresh token. Nothing in the flow announces the omission. ## Why the code condition exists An authorization code is redeemed at the token endpoint over a direct back-channel request from the client to the provider. Artefacts delivered by a response type that puts them in front of the browser travel through the user agent instead — through a redirect the user, the browser history and anything sitting in between can see. A refresh token is the longest-lived and most valuable artefact in the exchange: it buys fresh credentials, repeatedly, without the user. Requiring a code means the refresh token is only ever handed over on the back channel, in the token response, and never routed through a front-channel redirect. That is the entire point of the condition, and it is why "which leg does this travel on?" is the right question to ask of any long-lived artefact. ## Why the consent condition exists The second condition addresses a different risk: the end user cannot see what they are not shown. Unattended access is precisely the capability a user would want to be told about, so the specification requires the request to carry `prompt=consent` — the parameter value that asks the provider to obtain consent for this grant — unless the deployment already has other permitting conditions in place for offline access to those resources. That escape clause is deliberately written as an exception, not an alternative. In an integration where no such conditions have been arranged, `prompt=consent` is the requirement. ## Diagnosing the quiet failure In the nature reserve's species-sighting recorder, a nightly job reconciles each ranger's filed sightings against the reserve's survey plan while nobody is logged in. It needs `offline_access`. The integration is written, tested interactively, and works; the nightly job then fails every night with no credential. The diagnosis follows the two conditions, in order: - **Check the response type.** If the request does not use a response type that returns an authorization code, condition one failed and the value was discarded before anything else was considered. - **Check `prompt`.** If `prompt=consent` is absent and the deployment has arranged no other permitting conditions, condition two failed. - **Check the provider's advertised support.** `offline_access` still has to be a value the provider accepts, listed in `scopes_supported`. What will *not* show the problem is the ID token. It is issued exactly as it would have been, so an integration test that asserts "the user signed in" passes cleanly while the capability the job depends on was never granted. ## Two things worth not overstating - **A refresh token is not exclusive to `offline_access`.** The specification is explicit that the use of refresh tokens is not limited to the offline-access case. `offline_access` is the standard way to ask for one in OpenID Connect; it is not the only circumstance in which one is issued. - **Being granted one is not the same as asking.** The provider decides. A client must handle the case where it asked correctly, both conditions held, and the token response still contains no refresh token — because the end user declined, or because policy said no. ## The interview version The askable form is not "what does `offline_access` mean". It is the scenario above: a nightly job with no credential, an interactive flow that works, and a candidate who can name the two conditions, say which one to check first and explain why the code condition is about which channel the refresh token travels on.

  • Why ignore the value rather than return an error?
    Because the rest of the request is still a valid authentication request. Ignoring an unmet optional ask lets sign-in succeed, which is the behaviour the specification chose. The cost is that the failure is silent, so a client that depends on a refresh token must check the token response for one rather than assume the request implied it.
  • The request met both conditions and still no refresh token came back. What now?
    The conditions are necessary, not sufficient. The provider still decides: the end user may have declined at the consent step, or policy may forbid offline access for that client or those resources. A client must treat the absent refresh token as a real outcome and surface it, rather than retrying the same request forever.
  • Does offline_access change what the access token can do?
    No. It concerns whether the client can obtain fresh credentials later without the end user; it does not widen what any token permits at a resource server. Conflating "longer reach in time" with "more permission" is the usual confusion here.

saying these in an interview costs you the question

  • Thinks offline_access alone guarantees a refresh token
  • Expects an error when the conditions are unmet
  • Believes offline_access is the only source of refresh tokens
  • Says offline_access grants wider access at an API
  • Omits prompt=consent and blames the provider
  • Tests only the interactive flow and ships