Offline access and refresh behavior

Asking for offline access

Your sign-in at 09:00 asked only for openid profile email. It gave the printer no access to your photos and no refresh token, which suited a sign-in. The calendar needs something else, so the printer sends a separate authentication request to the return address it uses for photo connections:

https://auth.photos.example/authorize
  ?response_type=code
  &client_id=photo-printer
  &redirect_uri=https%3A%2F%2Fprinter.example%2Foauth%2Fcallback
  &scope=openid%20photos.read%20offline_access
  &prompt=consent
  &state=demo-attempt-8
  &nonce=demo-nonce-8
  &code_challenge=kPeoXcI0Ujq4KQcqIPlQawjpjjUu9V-tXHYDUACSnNM
  &code_challenge_method=S256

The offline_access scope asks for a refresh token that keeps working while you are away. OpenID Connect defines it narrowly, as a refresh token that can obtain access to your UserInfo endpoint even when you are not present, but its consent rules speak of offline access to whatever resources are requested. Providers commonly treat it as the request for a refresh token covering the whole grant, and the photo service does: the refresh token it issues here will obtain photos.read access tokens in December. Including openid makes this an OpenID Connect request, so an ID token comes back as well.

prompt=consent asks the photo service to show you a consent screen, even though you have approved the printer before. The specification requires it alongside offline access unless the provider has some other established basis for granting it, and it requires the provider to obtain your consent before returning a refresh token for offline use. An approval you gave earlier, for a sign-in, is not necessarily enough. An application that can act while you are away deserves a deliberate decision, and the provider should make the long-term access clear:

Photo Printer would like to:
  View your photos
  Keep this access when you are not using Photo Printer

If the printer left out prompt=consent and the photo service had no other basis for offline access, the specification tells the provider to ignore the offline_access request rather than refuse it. The authorization would succeed without a refresh token for offline use. A provider's own policy can also withhold refresh tokens from a client. So the printer checks what the token response contains, and if no refresh token arrives, it tells you now that the calendar cannot be set up, rather than discovering the problem in December.

You approve, and the token response looks familiar:

{
  "access_token": "demo-access-token-8",
  "token_type": "Bearer",
  "expires_in": 600,
  "refresh_token": "demo-refresh-token-3",
  "scope": "openid photos.read offline_access",
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6InBob3Rvcy1ycy0yMDI2LTA5IiwidHlwIjoiSldUIn0..."
}

The ID token is shortened here. The printer validates it as it validated your sign-in, against demo-nonce-8 this time, and records that the connection belongs to user-2048, the photo account you sign in with. The refresh token goes into the connection record that Server-rendered web applications described, tied to account 8812 rather than to the session that created it.

Refreshing in OIDC

On 1 December at 09:00, the calendar job sends demo-refresh-token-3 to the token endpoint. The request is exactly the one from The refresh token grant: the grant type, the refresh token, and the printer's client authentication. OpenID Connect adds nothing to it. The response adds one field:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "demo-access-token-9",
  "token_type": "Bearer",
  "expires_in": 600,
  "refresh_token": "demo-refresh-token-4",
  "scope": "openid photos.read offline_access",
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6InBob3Rvcy1ycy0yMDI2LTA5IiwidHlwIjoiSldUIn0..."
}

A provider may leave the ID token out of a refresh response, so the printer must not depend on getting one. When one is present, OpenID Connect restricts what it may say. Here are the claims of the December token beside those of the ID token from October's calendar authorization:

The identity claims cannot move. iss, sub, and aud must match the ID token from the original authentication, so a refresh can never produce a token about a different person or for a different client. iat and exp are new, because this is a new token with its own short lifetime.

auth_time does not move either, and it matters most. It must still give the time of the original authentication, 08:59:45 on 1 October, not the time of the refresh. Notice that the October value is already earlier than that token's iat. When you turned on the calendar, the photo service asked for your consent but did not ask you to authenticate again, because its session from your sign-in four minutes earlier was still running. No one authenticated in December at all. The token is new, but the authentication it describes is two months old.

The nonce is gone. A nonce ties an ID token to the authentication request that asked for it, and in December there was no authentication request, only a back-channel call from the printer's server. The specification says a refreshed ID token should not contain one, and if it does, the value must be the original's.

The printer validates the refreshed token as it would any ID token, including the signature with the photo service's key photos-rs-2026-09, and then compares it with what it recorded for the connection. A different sub, an auth_time later than the original, or a nonce other than demo-nonce-8 breaks those rules, and the job stops and marks the connection for attention rather than printing anyone's photos. Beyond that check, the calendar has no use for the token. The access token is what fetches the twelve photos.

Refresh is not presence

The December refresh succeeded while you were nowhere near a browser. It shows that your grant to the printer is still active, that the photo service still issues tokens for user-2048 to photo-printer, and that the printer holds the newest refresh token. It shows nothing more. You may not have been signed in at the photo service for weeks. The specification describes offline access as working when you are not logged in at all, and the refreshed ID token says so honestly: issued in December, about an authentication in October.

That makes one shortcut tempting and wrong. Your printer session reaches its absolute deadline on 8 October. A printer that wanted to keep you signed in longer could notice the expired session, refresh the calendar connection for account 8812, and treat the new ID token as a new sign-in. The token is genuine and names you, so this looks harmless. But the refresh involved only the printer's server and the photo service, never you or your browser. Whoever presented the expired cookie, perhaps someone at a library computer you forgot to sign out of, would get a fresh session. The absolute timeout would stop meaning anything, and the account would stay open as long as the refresh token family lasts, which Refresh tokens and rotation set at two years.

So a successful refresh never extends or creates a printer session. When the session ends, the printer sends the browser through the authorization endpoint for a new sign-in. The photo service may answer from its own session without asking you anything, or ask you to authenticate, but either way the result is a new ID token with a new nonce, bound to the pending sign-in in that browser. That is evidence about this browser, now, and a refresh token never passes through a browser at all.

The independence runs the other way too. A refresh that fails with invalid_grant means the connection needs you to reconnect. It does not sign you out of the printer, any more than signing out of the printer cancels the calendar. Nor do refresh results reveal your photo service session. Current security guidance allows a provider to revoke refresh tokens when you sign out of it, while offline access exists so that a grant can outlast your sessions there. Which the photo service does is its own policy.

When the printer genuinely needs to know whether you are present, the reliable way to find out is to send your browser to the photo service with an authentication request and see what comes back. The calendar request used prompt=consent to make sure you were asked. The same parameter can also ask the photo service not to show you anything at all, to insist on a fresh sign-in, or to let you choose between accounts, which Prompt and account selection takes up next.