Skip to content
TDACorpIDENTITY
Latest
Sign in

Token lifetimes

How long a session, a code, each token and each proof lives, with the public numbers in one place.

On this page

Every lifetime below is the value the platform applies when nothing else is set. Where an organization or a client can only make a lifetime shorter, the page says so. The operator of a deployment can also shorten most of the protocol and session values below (never lengthen them, and each has a floor), so a deployment can run with a smaller number than the one shown; the numbers here are the ceilings. Read expires_in and exp from what you receive. For what each item is for, read Sessions and tokens.

Sessions#

ItemLifetime
Session idle limit12 hours with no activity
Session absolute limit14 days after sign-in

An organization can set its own session lifetimes, and identity applies them when a person signs in for that organization. See Security practices for the platform statement.

Tokens and codes at the protocol endpoints#

ItemLifetimeNotes
Pushed authorization request reference60 secondsSingle use.
Authorization code60 secondsSingle use. Redeem it once, with the PKCE verifier.
Access tokenAt most 900 secondsA client's own value can only be lower. A newly registered client gets 600 seconds unless registered with another value.
ID tokenSame as the access tokenIt states an authentication that already happened.
Access token from client_credentialsThe client's access token lifetime600 seconds by default, at most 900. No refresh token is issued.
Refresh token, first-party clientThe client's registered lifetimeA newly registered client gets 30 days.
Refresh token, third-party clientAt most 7 days sliding and 30 days absoluteA client's registered value may be shorter, never longer.
Refresh token reuse grace10 secondsA retry of the same refresh inside this window receives the same new token.

A refresh token never outlives the session it came from, and a refresh is refused once that session has ended. If a retired refresh token is presented again after the grace window, identity revokes the whole family and ends the session.

Proofs and assertions#

ItemLifetime or window
DPoP proof iatAccepted within 60 seconds either side of the server clock
DPoP proof jtiRemembered for 5 minutes (never less than twice the iat window), so a proof can be used once
DPoP server nonceRotates every 5 minutes, and the previous nonce is still accepted
Client assertion (private_key_jwt)exp at most 5 minutes after it is issued, and each assertion is single use

See DPoP for how the SDK handles nonces and retries.

Sign-in links, codes and confirmations#

ItemLifetime
Sign-in in progressShort lived, and it is stopped after repeated failures
Emailed sign-in link or code15 minutes by default, single use, and it completes only in the browser that asked for it
Email verification link24 hours
Recovery link15 minutes, single use, bound to the browser that asked
Invitation7 days by default (the platform operator can change it), single use
Passkey challenge5 minutes by default (an operator can shorten it, to no less than 30 seconds), single use
Fresh confirmation for a sensitive account action30 minutes since the passkey, authenticator code, provider sign-in or account password you used (an operator can shorten this)

An organization can change the length of the emailed link. The other values on this table are fixed.

Personal access tokens#

A personal access token lasts the number of days you choose, from 1 to 365, or never if you choose that. It is shown once, and it works on the account profile only; see Account API at a glance.

What a short lifetime means for you#

  • An API that must react sooner than 15 minutes to a change in someone's access has to ask identity; see Authorization.
  • A refresh token that is not used inside its sliding window stops working, and the person signs in again.
  • If you see invalid_grant on a code you just received, it was probably used twice or took longer than 60 seconds. See Troubleshooting: invalid_grant.

Verified against commit 936c0b4