Prompt and account selection

Asking without interrupting

You signed in to the printer at 09:00 UTC on 1 October. By the next morning your printer session has expired, and you open printer.example again. The printer no longer knows who you are. It could show its sign-in page and wait for you to choose Continue with your photo account, but you probably still have a session at the photo service in this browser. If you do, a click that sends you there and straight back is wasted effort.

With prompt=none, the printer can find out without showing you anything. It sends its usual authentication request with one extra parameter:

https://auth.photos.example/authorize
  ?response_type=code
  &client_id=photo-printer
  &redirect_uri=https%3A%2F%2Fprinter.example%2Fsignin%2Fcallback
  &scope=openid%20profile%20email
  &state=demo-signin-4
  &nonce=demo-nonce-4
  &code_challenge=gwVlmAVBIZ7cJBaJAwIkTniP3Mp-iIrrGgr3DOJZNnk
  &code_challenge_method=S256
  &prompt=none

Apart from the last line, this is the request the printer always sends, with a new state, nonce, and PKCE pair for this attempt. prompt=none tells the photo service that it must not display any sign-in or consent page. It either answers from what it already knows or returns an error.

This morning the photo service still has your session, and you approved the printer's request when you first signed in. It returns a code without showing a page, and your browser is back at the printer almost before the address bar changes. The printer exchanges the code and validates the ID token as it would after any sign-in, including the nonce demo-nonce-4. One claim deserves a closer look:

{
  "iss": "https://auth.photos.example",
  "sub": "user-2048",
  "aud": "photo-printer",
  "iat": 1790928000,
  "exp": 1790928300,
  "auth_time": 1790845185,
  "nonce": "demo-nonce-4"
}

The token was issued at 08:00 on 2 October, but auth_time is still 08:59:45 on 1 October, the last time you actually used a credential at the photo service. Nothing new was authenticated this morning. The photo service only confirmed that this browser still holds your session, and like a refresh, that does not show you are the one using it. The printer creates a new session of its own and records the older auth_time, not the time of the silent check, because Session age and reauthentication will depend on the true value.

On a morning when you had signed out of the photo service, the same request would come back with an error instead:

https://printer.example/signin/callback
  ?error=login_required
  &state=demo-signin-4
  &iss=https%3A%2F%2Fauth.photos.example

The printer checks the state and issuer just as it would for a success, then shows its sign-in page as if it had never asked. For a silent check, an error is an ordinary answer, not a failure to investigate. These are the ones to expect:

What the printer must not do is try again on its own. A printer that answers login_required with another prompt=none request, or that runs a silent check on every page load, can bounce your browser back and forth without end. One silent check when a visit starts is enough. After that, the next request to the photo service should be an interactive one that you started by choosing to sign in.

Applications that run in the browser once made these checks in a hidden frame, loading the authorization request in an invisible iframe so the page never navigated away. That pattern no longer works reliably. Inside a frame on printer.example, the photo service is a third party, and browsers increasingly withhold third-party cookies: some block them or keep a separate cookie jar for each site by default, and the others let people turn them off. When the photo service cannot see its own session cookie, it answers login_required even though you are signed in. The check works as a top-level redirect like the one above, where the photo service's cookies are first-party.

Asking again

Sometimes the printer wants the opposite: an interaction the photo service would otherwise skip.

prompt=login asks the photo service to authenticate you again even though you have a session. If it cannot, it returns an error, typically login_required. The printer would use it when it needs evidence that the person at the keyboard can still sign in as you, not only that this browser holds your session. Session age and reauthentication follows that case, and shows why the printer then checks auth_time itself instead of trusting that its request was honored.

prompt=consent asks the photo service to show its consent screen even if you have approved this request before. If it cannot obtain consent, it returns consent_required. Offline access is the case the specification names: a request for offline_access carries prompt=consent because an earlier approval is not always enough for access that continues while you are away. A client might also use it when it wants you to look again at what you are sharing. The consent screen still belongs to the photo service. The printer can ask for it to appear, but it cannot change what it says.

The parameter takes a space-separated list, so prompt=login consent asks for a fresh sign-in and a consent screen. The exception is none, which must stand alone. A request with prompt=none login asks for no pages and a sign-in page at once, and the photo service returns an error instead of guessing which the printer meant.

Choosing an account

You also keep a second photo account, which you use for a neighborhood photography club. The photo service lets you stay signed in to both in the same browser and switch between them. When the printer sends an ordinary request, the photo service picks one for you, often the one you used last. If that happens to be the club account, the printer receives a perfectly valid sign-in for an account you did not mean to use, and it may create a new, empty printer account to go with it.

The printer's sign-in page can offer a way out, a link labeled Use a different photo account, which sends prompt=select_account. The photo service then shows its account chooser, even if it could have picked an account itself. If it cannot get a choice from you, it returns account_selection_required.

The chooser is the photo service's page, not the printer's. The printer never learns which other accounts you have. It receives only the sign-in for the one you picked, validated and looked up by its issuer and subject like any other.

One more value comes from a separate, newer specification, Initiating User Registration via OpenID Connect. prompt=create, sent on its own, asks the provider to open its account creation page instead of its sign-in page, so a printer customer without a photo account can go straight to signing up. What happens on that page is the provider's decision, and someone who already has an account may simply sign in with it, so the printer cannot assume an account was created. It handles the response like any other sign-in. A provider that supports the value lists create in the prompt_values_supported field of its discovery document, and the printer offers its sign-up link only then, because a provider that does not recognize a prompt value may reject the request or quietly ignore the value.

An account chooser asks you which account the printer should receive. When the printer already knows which one it expects, it can say so instead, and Login hints covers how.