skip to content

In OpenID Connect, which authentication-request parameter makes a provider re-prompt a user who already has a session there?

level: juniorimportance: should knowfreq 40%

answer

  1. default is reuse, not re-ask
  2. one parameter, four defined values
  3. asks the provider, not your own session
  4. login is a SHOULD for the provider
  5. error typically login_required

basics

~20 s

prompt=login on the authentication request asks the provider to re-authenticate the user even though a provider session already exists. Without it, a provider may answer from that session silently, so the browser bounces out and back with no sign-in shown.

solid answer

~40 s

By default an OpenID Connect authentication request says nothing about how the person should be authenticated, so the provider may answer it from a session that user already has there — the redirect goes out and comes straight back with nothing displayed. Adding `prompt=login` asks the provider to re-authenticate the user for this request. The specification makes that a SHOULD for the provider: if it cannot re-authenticate, it MUST return an error instead of a success, typically `login_required`. Two things it does not do: it does not end anything, and it does not touch the relying party's own application session, which the protocol never manages. `max_age` is the other way to ask the same sort of question — not "ask again now" but "the last authentication may be at most this many seconds old".

code

http · 5 lines
http
GET /authorize?response_type=code&client_id=lab-cases
  &redirect_uri=https%3A%2F%2Fcases.example%2Fcb
  &scope=openid&state=af0ifjsldkj&nonce=n-0S6_WzA2Mj
  &prompt=login HTTP/1.1
Host: provider.example

go deeper

for a junior

Recall that a provider may answer an authentication request from a session the user already holds there, and that prompt=login is how a request asks for a fresh sign-in instead of that silent reuse.

for a middle

Explain that prompt=login is a SHOULD for the provider, that a provider unable to re-authenticate returns an error such as login_required, and that nothing in the protocol touches the relying party's own session.

for a senior

Show how you confirm a re-authentication actually happened rather than trusting the parameter: read what the provider reports about when the user authenticated, and define what your service does when it did not.

for a principal

Frame where re-prompting belongs at all. Every forced sign-in spends user patience, so the decision worth owning is which operations justify one and who maintains that list as the product grows.

## What an authentication request assumes when it says nothing An OpenID Connect authentication request is a redirect from a relying party — a dental laboratory's case-tracking site, say — to a provider's `authorization_endpoint`, carrying at least `scope=openid`, a `client_id`, a `redirect_uri` and a `response_type`. By default it says nothing about **how** the person at the keyboard should be authenticated, and the provider is free to answer it from a session that person already holds there. The browser leaves the site, arrives at the provider, and returns immediately with no sign-in form shown. That is not a bug; it is precisely what makes single sign-on feel like single sign-on. It stops being what you want the moment one operation carries more weight than the rest. Browsing the laboratory's case queue is one thing; releasing a patient's case record back to a practice is another. For the second, the site wants the provider to ask again — without throwing the user out of everything else they were doing. ## The `prompt` parameter `prompt` is a space-delimited, case-sensitive list of values on the authentication request. Four values are defined: `login`, `none`, `consent` and `select_account`. The one that forces a fresh ceremony is **`login`**: it asks the provider to re-authenticate the end user for this request regardless of what session already exists. Two details matter more than the spelling of the value: 1. **It is a SHOULD for the provider, not a MUST.** The specification says the provider SHOULD prompt the end user for re-authentication; if it cannot, it MUST return an error rather than a successful response — typically `login_required`. A relying party that concludes "I sent `prompt=login`, therefore the user just authenticated" has assumed a guarantee the parameter does not give. 2. **It changes what happens at the provider only.** Nothing about it reaches back into your own application's session. ## Which session is actually being re-authenticated "The session" means at least three different things in one sentence on this material, and mixing them up is the commonest way this parameter is misunderstood. | Session | Who owns it | Does `prompt=login` affect it? | |---|---|---| | The end user's authenticated session at the provider | the provider | Yes — the provider is asked to re-authenticate for this request | | The relying party's own application session and its cookie | your application | No — the protocol never creates, refreshes or ends it | | The browser's cookie jar for each site | the user agent | No — nothing is cleared | So `prompt=login` is a request about the first row. Whether your application then treats the returned response as grounds for elevating its own session is your code's decision, made after the response arrives. ## Confirming it rather than assuming it The provider reports **when** the user last actively authenticated through a claim in the ID token it returns, and a request that carries `max_age` obliges the provider to include that claim. Checking what came back — rather than trusting that the parameter was honoured — is the habit worth forming early; the validation rules for the returned claims belong with ID token validation, but the shape of the reasoning is simple: the request is an ask, the response is the evidence. ## Two ways to ask for a sign-in that is not stale - **`prompt=login`** names the *interaction*: ask this user again, now. - **`max_age`** names the *freshness*: the last active authentication may be at most this many seconds old, and if the elapsed time is greater the provider MUST attempt to re-authenticate. A single request may carry both, and they are not redundant: one asks for an event, the other states a bound. A provider that cannot meet either answers with an error rather than a successful response. ## What this parameter is not - **Not a logout.** Ending the user's session at the provider is a separate request to a different endpoint, the `end_session_endpoint`, with its own parameters. - **Not an authorization decision.** It says nothing about what the resulting access token may do at an API. - **Not consent.** Re-consent is `prompt=consent`, a different value with a different meaning and its own error code. - **Not a silence switch.** The opposite value, `none`, is the one that forbids any interface at all. The practical rule for a junior integration: leave `prompt` off for ordinary sign-in so single sign-on works, reach for `login` only where the operation justifies interrupting someone, and read what the provider says came back rather than assuming the interruption occurred.

  • What does a provider return if it cannot re-authenticate the user after `prompt=login`?
    An error response rather than a successful one, delivered to the registered `redirect_uri` with the `state` echoed back. The specification names `login_required` as the typical code. The relying party must treat that as a normal protocol outcome and decide what to do, not as a transport failure to retry blindly.
  • Does `prompt=login` affect the relying party's own application session?
    No. OpenID Connect governs the exchange with the provider; the application's own session and its cookie are outside the protocol entirely. If your service wants to require a fresh sign-in before an operation, it must check what the response says about the authentication and act on that itself — the parameter alone changes nothing locally.
  • Can `prompt` carry more than one value?
    Yes, it is a space-delimited list, so `login consent` is a legitimate request. The one restriction is `none`: a request that combines `none` with any other value is an error, because asking for no interface and for an interface at the same time is contradictory.

saying these in an interview costs you the question

  • Thinks a provider re-authenticates on every authentication request by default
  • Assumes re-authentication happened because the parameter was sent
  • Says prompt=login ends the user's session at the provider
  • Believes prompt=login clears the relying party's application cookie
  • Treats prompt=login as an obligation the provider cannot refuse