Configure token and session expiry

Tokens are an essential part of keeping your application secure. They enable the continued verification of users and applications (including APIs), and are a mechanism for detecting unauthorized intruders.

Tokens need to be updated and refreshed to remain secure, which is why you need to set how long a token lasts, for each token type.

What are the default token lifetimes in Kinde?

Link to this section

Kinde issues three types of tokens, each with a default lifetime that applies out of the box. All values are configurable per application in Settings > Environment > Applications > [your app] > Tokens.

Token	Default lifetime
Refresh token	15 days (1,296,000 seconds)
Access token	24 hours (86,400 seconds)
ID token	1 hour (3,600 seconds)

The refresh token lifetime must always be set longer than the access token lifetime. For guidance on each token type, see the dedicated pages: access tokens, ID tokens, and refresh tokens.

Defining token lifetimes

Link to this section

You can define the lifetime (expiry time) of ID tokens, access tokens, refresh tokens, and SSO session expiry tokens. Expiry and timeouts are usually defined in seconds - where 3,600 seconds is one hour and 86,400 seconds is one day. Tokens and sessions need to be configured per application.

• ID Tokens: Contain identity information about a user. These do not need to last long as identity info is only needed at the moment of authentication, and is unrelated to session lifetimes.
• Access tokens: Contain access permissions for a user during authentication. These are the most vulnerable token for attacks, and we do not recommend extending the access token lifetime beyond 1 day.
• Refresh tokens: Are issued at the same time as an access token, and extend a user’s session without them having to reauthenticate. If you want a user to stay authenticated without having to sign in daily or more frequently - set a high lifetime for refresh tokens.
• Session inactivity timeout: After a period with no server-visible activity on the user’s Kinde SSO session, the user may need to sign in again. Local navigation in your app does not reset the timer on its own; activity usually means authenticated requests from your app to Kinde for that user (for example, during token refresh). See Session management for a full explanation. We recommend a fairly short limit (for example, up to one day).

Token and session expiry should be approached with priority for system and user security. The aim is to reduce risks such as:

• Token theft through man-in-the-middle attacks
• Unauthorized access through compromised refresh tokens
• Session hijacking on shared or public devices
• Data exposure through prolonged inactive sessions

Set token lifetimes

Link to this section

1. Go to Settings > Environment > Applications.
2. Select View details on the application tile.
3. Select Tokens in the side menu.
4. For each token type, set the expiry time in seconds. 3,600 seconds is one hour; 86,400 seconds is one day.
5. Select Save.

Refresh token cookies

Link to this section

For applications that support refresh tokens, the Tokens page includes a Refresh token cookies fieldset with the following option.

Use client-specific refresh token cookies

Link to this section

When this toggle is enabled, refresh tokens are stored in cookies named with the client ID prefix (for example, refresh_token_abc123) instead of the generic refresh_token cookie. That allows multiple applications on the same custom domain to keep separate refresh tokens and avoids one app overwriting another’s token.

• Default: The toggle is disabled by default.
• Custom domain required: The option is only available when a custom domain is configured. If no custom domain exists, a warning banner is shown: “Client-specific refresh token cookies require a custom domain. Configure a custom domain in Settings > Custom domains.”

Revoke a token to end a user session

Link to this section

You can use the Kinde Account API to revoke access and refresh tokens after a user signs out of your app. This forces a new session for each login.

To revoke a previously issued token, you need to make a POST request to the /oauth2/revoke endpoint with the operation ID tokenRevocation. When making the request, you should include the following parameters in the request body:

• token (string): The token that you want to revoke.
• client_id (string): Your client’s identifier.
• client_secret (string): The secret associated with your client. Ensure to set the Content-Type header to application/x-www-form-urlencoded.

Upon successful revocation, you will receive a 200 status code indicating that the token was successfully revoked. For more information and example code snippets, see revoke tokens.

To end all of a specific user’s sessions from your backend rather than revoking one token at a time, see End a user’s sessions from your backend.

What revocation does and doesn’t do

Link to this section

Revoking a token or ending a user’s sessions takes effect immediately for everything Kinde holds server-side. It does not reach access tokens that have already been issued.

What you revoke	Effect
SSO (authenticated) session	Ends immediately. The user must sign in again to start a new session.
Refresh token	Invalidated immediately. The next refresh attempt fails with invalid_grant.
Access token already held by an app	Remains valid until it expires.

This is a property of JWTs, not a Kinde limitation. Access tokens are self-contained and signed, so your API validates them locally against Kinde’s public keys, checking the signature, issuer, audience, and expiry. That check never calls Kinde, which is what makes it fast and keeps Kinde out of your request path. The trade-off is that no identity provider can reach into a token that has already been handed out.

In practice, an access token already held by an app keeps working until exp, even after you revoke sessions or refresh tokens, or suspend or delete the user. That remaining window is at most the access token lifetime you configured — up to 24 hours with the default.

Suspension or deletion also stops the user from signing in and from obtaining new tokens. Revoking a session or refresh token does not: the user must reauthenticate, but they can sign in again immediately.

Close the window

Link to this section

Shorten the access token lifetime. This is the control to reach for. The remaining validity window for the revoked session is at most the configured access token lifetime, so lowering it is the most direct fix. A 5 to 15 minute access token paired with refresh tokens means remaining access for that session ends within minutes after revocation, because subsequent refreshes for the revoked session fail. Shortening the lifetime does not prevent the user from signing in again. See Set token lifetimes above.

Shortening the access token lifetime increases the number of refresh calls your app makes. Test the value you choose against your traffic before rolling it out broadly.

Check live state, very sparingly. The /oauth2/introspect endpoint validates a token against current session state, so it reflects revocation immediately. It also puts Kinde back in your request path, which is the thing local JWT validation exists to avoid. Reserve it for a small number of genuinely high-value actions where a short token lifetime is not enough on its own. Do not use it for routine request authorization.

Token security

Link to this section

Tokens can be vulnerable to security breaches. Access tokens in particular contain sensitive information, and these tokens can be used to access systems.

Refresh tokens can be used to reduce some of this risk as they can be used to get new access tokens. However, refresh tokens are also a security risk for the same reason they are useful.

To mitigate risk, we recommend using Automatic Reuse Detection and Refresh Token Rotation.

Setting up an automation to revoke tokens after logout can enhance security as it forces re-authentication each sign in.