Loading

Lifetimes, Keys and Revocation

Tokens expire, keys rotate, and access is revoked. These are the settings that decide how quickly a decision here takes effect out there.

Where to find it

Architect Panel → Integration & Connections:

  • OpenID Connect Provider — the console — clients, scopes, keys and the log

Architect Panel → Security:

  • Disabled User Accounts — the fastest way to cut somebody off
  • Certificates — signing material

Four lifetimes

  • Access token — how long a token is accepted. Short.
  • Identity token — how long the identity assertion is valid.
  • Refresh idle — how long a refresh token survives without being used.
  • Refresh absolute — the hard ceiling, however often it is used.

Short access, bounded refresh

Keep access tokens short — minutes to an hour. Their length is the window in which a leaked one is useful, and a refresh token exists precisely so a short access token is not inconvenient.

Then bound the refresh. The idle timeout drops abandoned sessions; the absolute one forces a fresh sign-in eventually regardless. Without an absolute ceiling, a refresh token used weekly lasts for ever, and "signed in since 2024" is not a session anybody decided to grant.

Rotating signing keys

Clients fetch your public keys automatically, so rotation needs no coordination — if you do it in the right order:

  1. Publish the new key alongside the old.
  2. Start signing with the new one.
  3. Wait for every token signed with the old key to expire.
  4. Remove the old key.

Removing it at step 2 invalidates every outstanding token at once. That is a way to sign everybody out immediately — occasionally useful, rarely intended.

What revocation actually does

The important thing to be clear about: revoking a token stops future use of it. It does not reach into an application and end a session that application is maintaining from an access token it already holds.

So the practical answer to "cut this person off now" is:

  1. Disable the account. This is the effective control — nothing further can be issued, and refresh stops working.
  2. Revoke their outstanding tokens.
  3. Accept a short residual window equal to your access token lifetime.

That window is exactly why access tokens should be short. If yours are a day long, "immediately" means tomorrow.

Removing a client

Disabling a client stops it obtaining anything new. Users who had signed in may continue until their tokens lapse, for the same reason.

Test revocation before you need it

Disable a test account, then see how long it takes for a connected application to notice. That number is your real answer to "how quickly can we cut somebody off", and it is better known in advance than discovered during an incident.

Worked example

An organisation sets access tokens to fifteen minutes, refresh idle to fourteen days and refresh absolute to ninety. When a member's access is withdrawn, their account is disabled; the connected events site stops working within fifteen minutes without anybody contacting the agency.

Recommendations

  • Short access tokens — they define your revocation window.
  • Always set an absolute refresh ceiling.
  • Rotate keys by overlapping, never by replacing.
  • Disable the account to cut someone off, and test how long it takes.