Skip to main content
Identity Authority
Category: Tokens & Sessions

Token Lifetime

Also known as: Token Expiration, Token Validity Period
Simply put

Token lifetime is the length of time during which an issued token remains valid before it expires. Once a token expires, the client typically must obtain a new one, which may require reauthentication or use of a refresh token depending on the deployment. Shorter lifetimes reduce the risk if a token is stolen, while longer lifetimes reduce how often clients must renew.

Formal definition

Token lifetime is the configurable or default validity period assigned to an issued token, commonly an access token, but also ID tokens or SAML assertions depending on the platform, after which the token is considered expired and should be rejected during validation. In the Microsoft identity platform, for example, an access token's default lifetime is assigned a randomized value between 60 and 90 minutes (averaging roughly 75 minutes), while long-lived token configurations range from approximately 20 to 28 hours; exact behavior varies by vendor, token type, and configured policy. Shorter lifetimes limit the exposure window if a token is compromised, which is often favored for machine-to-machine and API access, at the cost of more frequent token renewal. When an access token expires, the client typically must acquire a new token, often via a refresh token or by reauthenticating, rather than continuing to present the expired credential. Token lifetime governs the runtime validity window and is distinct from, though related to, revocation and refresh-token rotation; the specific policies configurable (for access, ID, and SAML tokens) depend on the identity platform in use.

Why it matters

Token lifetime directly governs the window of opportunity available to an attacker who obtains a valid token. Because bearer tokens such as OAuth 2.0 access tokens are typically honored by resource servers on presentation, without re-checking the original authentication, a stolen token remains usable until it expires (or, where supported, is revoked). Shorter lifetimes shrink this exposure window, which is why they are often favored for machine-to-machine and API access where reauthentication is cheap or automated. Longer lifetimes reduce renewal overhead but leave a compromised token valid for longer.

The tradeoff is a balancing act rather than a universally correct setting. Setting lifetimes too short can increase load on token endpoints and degrade user or client experience through frequent renewal; setting them too long weakens the security benefit of expiration. In most deployments the choice depends on token type, the sensitivity of the protected resource, and whether refresh tokens or revocation mechanisms are available as compensating controls. It is worth noting that lifetime alone does not provide immediate containment: a self-contained token, once issued, generally remains valid for its full lifetime regardless of later events unless the platform supports revocation or short-lived issuance, so lifetime settings should be evaluated alongside those mechanisms rather than in isolation.

Who it's relevant to

Security Architects
Architects set token lifetime policy as part of the broader tradeoff between attack-surface containment and operational overhead. They must weigh short lifetimes against the availability of refresh tokens and revocation, and decide policies per token type and resource sensitivity rather than applying a single value everywhere. Because a valid token is typically honored until expiry, lifetime is a core input to threat models covering token theft and replay.
IAM Engineers
Engineers configure and test lifetime settings on the identity platform, for access, ID, and SAML tokens where the platform supports it, and implement the client-side renewal flows that acquire new tokens via refresh tokens or reauthentication when a token expires. They also need to account for platform behaviors such as randomized default access-token lifetimes when reasoning about renewal timing and testing edge cases around expiration.
System Administrators
Administrators operate the deployments where lifetime settings translate into real-world renewal frequency and user or client experience. Overly short lifetimes can increase token-endpoint load and prompt frequent renewal, while overly long ones extend exposure. Admins monitor for expiration-related failures and ensure renewal paths function as configured.
Compliance Officers
Compliance and audit stakeholders may need to demonstrate that token validity windows align with organizational access-control requirements. Because token lifetime affects how long access persists after issuance, it can be relevant to evidence around session control and credential exposure limits, though it should be assessed alongside revocation and refresh-token handling, not as a standalone control.

Inside Token Lifetime

Access Token Lifetime
The validity period configured for an access token, which authorizes a client to call protected resources. In most deployments these are kept relatively short-lived to limit the window of misuse if a token is leaked, though the exact duration varies by vendor and deployment context.
Refresh Token Lifetime
The validity period for a refresh token, which is used to obtain new access tokens without re-authenticating the user. Refresh tokens are typically longer-lived than access tokens and may be subject to rotation or sliding-window expiration depending on configuration.
ID Token Lifetime
The validity period of an OpenID Connect ID token, which conveys authentication claims about the end user to the client. Its lifetime governs how long the client may treat those authentication claims as fresh, distinct from the access token's authorization scope.
Absolute vs. Sliding Expiration
Absolute expiration fixes a hard end time from issuance, while sliding (or renewable) expiration extends validity on continued activity up to a maximum limit. The chosen model determines how session continuity balances against re-authentication requirements.
Expiration Claims
For self-contained tokens such as JWTs, time-based claims (commonly exp for expiry, iat for issued-at, and nbf for not-before) encode lifetime information that a resource server validates. For opaque tokens, lifetime is typically tracked server-side and checked via introspection rather than encoded in the token itself.
Revocation and Early Termination
Mechanisms that end a token's usable life before its scheduled expiry, such as refresh token revocation or introspection returning an inactive status. This matters most for self-contained tokens, which are generally hard to revoke mid-lifetime without additional infrastructure.

Common questions

Answers to the questions practitioners most commonly ask about Token Lifetime.

Does a longer access token lifetime automatically weaken security?
Not automatically, though it does change the risk profile. A longer access token lifetime typically widens the window during which a leaked or stolen token remains valid, because self-contained tokens such as JWTs are usually accepted until they expire regardless of intervening changes. However, security depends on the whole design, including whether revocation, token binding, or short refresh cycles are in place. In most deployments the tradeoff is between the exposure window and the operational cost of frequent re-validation, so calling a longer lifetime universally weaker overstates the case. Evaluate it in the context of your revocation strategy and token type rather than as an absolute.
Does setting a token lifetime mean a revoked or terminated user immediately loses access?
Usually not, and this is a common misconception. For self-contained tokens like signed JWTs, the resource server typically validates the signature and expiry locally without contacting the issuer, so a token often remains accepted until it expires even after the underlying account is disabled or access is revoked. Immediate revocation generally requires additional mechanisms such as token introspection for opaque tokens, short access token lifetimes paired with refresh token checks, or a revocation or denylist check at the enforcement point. Token lifetime governs natural expiry, not real-time revocation, and the two should be treated as separate controls.
How do access token and refresh token lifetimes typically relate to each other?
In many OAuth 2.0 and OIDC deployments, access tokens are given a relatively short lifetime while refresh tokens are given a longer one, so that a client can obtain new access tokens without re-prompting the user. The short access token lifetime limits the exposure window for a leaked access token, while the refresh token, which is typically handled more securely and can be revoked at the authorization server, governs the longer session. Exact durations vary by vendor, profile, and deployment context, and some deployments add refresh token rotation so each use issues a new refresh token and invalidates the prior one.
How can short access token lifetimes be reconciled with the desire for immediate revocation?
A common pattern is to pair short-lived access tokens with a longer-lived but revocable refresh token, so that revoking access at the authorization server takes effect the next time the client attempts to refresh. This bounds the residual access to roughly the remaining access token lifetime. Depending on configuration, alternatives include using opaque tokens with token introspection at the enforcement point, or maintaining a revocation or denylist check. Each approach trades off latency, network dependency, and infrastructure complexity, so the choice generally depends on how quickly revocation must propagate in your environment.
What factors typically influence how token lifetime is configured?
Configuration usually balances several factors: the sensitivity of the protected resources, the exposure window acceptable for a leaked token, user experience considerations around re-authentication frequency, and the availability of revocation mechanisms. Whether tokens are self-contained or opaque also matters, since introspection allows near-real-time invalidation while self-contained tokens generally do not. Regulatory or organizational policy, step-up authentication requirements, and client type (for example a confidential server-side client versus a public single-page application) also commonly shape the chosen values. Specific durations vary by vendor defaults and standard profiles.
Should ID tokens and access tokens use the same lifetime?
Not necessarily, because they serve different purposes. In OpenID Connect, the ID token conveys authentication information about the end user to the client and is typically consumed shortly after issuance, whereas the access token is presented to resource servers for authorization over the course of API calls. Because their roles differ, deployments often configure them independently, and the appropriate lifetime for each depends on how the client uses them. Treating them as a single value can be a mistake, since the ID token is generally not intended for repeated presentation to APIs the way an access token is.

Common misconceptions

A short token lifetime alone provides strong security.
Lifetime is one control among several. A short-lived access token limits the exposure window, but security also depends on transport protection, token binding, revocation capability, and how refresh tokens are handled. Depending on configuration, a long-lived or poorly protected refresh token can undermine the benefit of short access token lifetimes.
Once a self-contained token like a JWT is issued, it can be reliably revoked before its expiry.
Self-contained tokens are typically validated by inspecting their signature and claims without a call back to the issuer, so they generally remain valid until they expire unless the deployment adds revocation checks such as introspection or a denylist. Opaque tokens are usually easier to revoke because they are validated against server-side state.
The ID token and access token can share the same lifetime because they serve the same purpose.
They serve different purposes: the ID token conveys authentication claims about the user, while the access token authorizes resource access. Their lifetimes are configured independently, and treating them as interchangeable conflates authentication freshness with authorization scope.

Best practices

Keep access tokens short-lived to limit the exposure window if one is leaked, and rely on refresh tokens for continuity rather than extending access token validity.
Configure refresh token handling deliberately, considering rotation and maximum sliding-window limits, since a long-lived refresh token can offset the benefit of short access tokens.
For self-contained tokens, add a revocation or introspection path where mid-lifetime termination is required, rather than assuming expiry alone provides timely invalidation.
Set ID token lifetime according to how long authentication claims should be treated as fresh, independently of the access token's authorization lifetime.
Validate time-based claims (exp, nbf, iat where present) on every request at the resource server, and account for clock skew per your deployment's tolerance.
Choose absolute versus sliding expiration based on your session continuity and re-authentication requirements, and document the maximum lifetime so it can be reviewed and audited.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide