kinde-oss · onderay · Sep 18, 2026 · Aug 28, 2026 · Aug 31, 2026 · Aug 31, 2026
@@ -7,14 +7,17 @@ relatedArticles:
   - 6f5b7b0d-3818-4654-a1a1-3247a5e4d52a
   - 5a248c6f-c1ae-480a-95c3-d3c69c81598d
   - 4ed081b0-7853-49be-b5fd-22a84a86bdad
-description: >-
-  Guide to managing Kinde authenticated sessions including session persistence,
-  inactivity timeouts, and browser session behavior.
+tableOfContents:
+  maxHeadingLevel: 3
+description: "Set SSO persistence and inactivity timeouts, then end user sessions from your backend with the Management API"
 featured: false
 deprecated: false
 topics:
   - authenticate
-sdk: []
+  - manage-authentication
+  - sso
+sdk:
+  - kinde-management-api
 languages: []
 audience:
   - developer
@@ -23,41 +26,69 @@ complexity: intermediate
 keywords:
   - session management
   - SSO session
-  - session cookies
   - inactivity timeout
-  - browser session
-updated: 2026-04-13
+  - persistent cookies
+  - delete user sessions
+  - refresh tokens
+  - sign out everywhere
+  - session cookies
+ai_summary: "Guide to managing Kinde authenticated SSO sessions at the application level. Covers persistent versus non-persistent session cookies, SSO session inactivity timeout (default 86400 seconds), and dashboard steps under Settings, Environment, Applications, Sessions. Explains that these settings apply only to Kinde sessions, not sessions your app maintains, and links to organization-level session configuration. Documents cookie limitations such as surviving tab close and browser session restore. Explains how to end all of a user's sessions from a backend using DELETE /api/v1/users/{user_id}/sessions with an M2M application and the delete:user_sessions scope, including that refresh tokens are invalidated immediately while issued access tokens remain valid until expiry. Clarifies that ending sessions does not delete or suspend the user. FAQ covers what counts as inactivity (authenticated calls to Kinde such as token refresh, not local app browsing or M2M) and how switching organizations via login with orgCode updates a shared refresh_token cookie across tabs. Intended for developers and product managers."
+updated: 2026-08-31
 ---
 
-You can manage Kinde authenticated sessions via your application settings. An authenticated session (or SSO session) is the period during which Kinde treats the user as signed in. You can define whether a session persists after the browser is closed, and how much time can elapse before prompting a user to re-authenticate.
+You can manage Kinde-authenticated sessions via your application settings. An authenticated session (or SSO session) is the period during which Kinde treats the user as signed in. You can define whether a session persists after the browser is closed, and how much time can elapse before prompting a user to re-authenticate.
 
 These settings only apply to Kinde sessions and not sessions you maintain through your own application.
 If you want, you can [change session settings for an organization](/authenticate/manage-authentication/session-management-per-organization/), without affecting other organizations. 
 
+## Manage SSO session behaviors and policies
+
+Session settings are managed on a per-application basis. Do the following to manage them:
+
+1. Sign in to your Kinde dashboard.
+2. Go to **Settings > Environment > Applications.**
+3. Select **View details** on the application tile you want to manage.
+4. Select **Sessions** in the side menu.
+
+    ![session management in kinde](https://imagedelivery.net/skPPZTHzSlcslvHjesZQcQ/2253664a-70b9-4cc7-c22f-2a07fab63000/socialsharingimage)
+
+5. In the **SSO sessions** section, decide on the policy for session cookies:
+    - Persistent: Keep the session active even if the user closes their browser.
+    - Non-persistent: End the session when the user closes their browser (some [limitations](#limitations) apply). 
+6. In the **SSO session inactivity timeout** section, set how long a session can be inactive before prompting re-authentication. This setting is applied in seconds. Default is `86400` seconds (one day).
+7. When you're finished, select **Save**.
+
 ## Limitations
 
 - Session cookies are not destroyed when a tab is closed, the full browser window must be closed.
 - Modern browsers usually allow session restoration. Restoring a browser session can also restore a session cookie.
 
-## Manage SSO session behaviors and policies
+## End a user's sessions from your backend
+
+The session settings above control how long a session lasts on its own. You can also end a user's sessions on demand from your own backend, using the Management API. This is useful when an admin deactivates an account, when you detect suspicious activity, or when you want a "sign out everywhere" control in your app.
+
+Call `DELETE /api/v1/users/{user_id}/sessions` using an M2M application with the `delete:user_sessions` scope. See the [Management API reference](/kinde-apis/management#tag/users) for request and response details.
+
+This ends the user's SSO sessions and invalidates their refresh tokens immediately. Access tokens their app already holds remain valid until they expire, because those are validated locally by your API rather than checked against Kinde on each request. For how to narrow that window, see [What revocation does and doesn't do](/build/tokens/configure-tokens/#what-revocation-does-and-doesnt-do).
+
+<Aside>
+
+Ending sessions does not delete or suspend the user. They can sign in again straight away. To prevent sign-in entirely, [suspend or delete the user](/manage-users/access-control/delete-or-suspend-users/).
+
+</Aside>
 
-1. Go to **Settings > Environment > Applications.**
-2. Select **View details** on the application tile.
-3. Select **Sessions** in the side menu.
-4. In the **SSO sessions** section, decide on the policy for session cookies. A persistent session leaves the cookie active when the browser is closed. A non-persistent session is terminated when the browser window closes (unless the limitations listed above apply). 
-5. In the **Session inactivity timeout** section, set how long a session can be inactive before prompting re-authentication. This setting is applied in seconds - where 3,600 seconds is one hour; 86,400 seconds is one day.
-6. When you're finished, select **Save**.
+## FAQ
 
-## What counts as activity for SSO session inactivity?
+### What counts as activity for SSO session inactivity?
 
 Kinde measures inactivity **on the server**. Browsing your own app—switching pages or using the UI—does not reset the timer **unless** that work leads to **authenticated calls to Kinde** for the signed-in user. **Token refresh** is a familiar example: when your app or SDK exchanges a refresh token at Kinde, that interaction can count as activity for this timeout.
 
 There is **no public list of every action** that resets inactivity. In practice, treat **authenticated, end-user-facing traffic to Kinde** as the model, rather than assuming every client-side event is visible to Kinde.
 
 **Machine-to-machine (M2M)** integrations and the **Management API** use separate credentials and contexts. They are **not** equivalent to activity on a specific person’s browser SSO session when you interpret this setting.
 
-## Does switching organizations affect other browser tabs?
+### Does switching organizations affect other browser tabs?
 
 Yes. When a user switches to a different organization (by calling `login({ orgCode })` from your app), a new refresh token for that organization is issued and stored in the `refresh_token` cookie. Because this cookie is shared across all tabs on the same domain, other tabs that were authenticated to a different organization will use the new cookie on their next token refresh — and will then be operating in the context of the most recently signed-in organization.
 
-If your application needs each browser tab to maintain an independent org context, you will need to manage org tokens at the application layer (for example, storing org-specific tokens in tab-local state rather than relying on the shared cookie).
+If your application needs each browser tab to maintain an independent org context, you will need to manage org tokens at the application layer (for example, storing org-specific tokens in tab-local state rather than relying on the shared cookie).
@@ -1,18 +1,20 @@
 ---
 page_id: d8069575-dfef-421d-8f3a-8f3efe9ad2f3
 title: Access tokens
-description: Comprehensive guide to Kinde access tokens including standard JWT claims, Kinde-specific claims like organization codes and feature flags, and token behavior during refresh operations.
+description: "Inspect Kinde access token claims, lifetimes, and refresh behavior so you can authorize APIs with confidence"
 sidebar:
   order: 2
 relatedArticles:
   - 5a248c6f-c1ae-480a-95c3-d3c69c81598d
   - cf687bce-9732-4b67-9da5-580953c8549f
+tableOfContents:
+  maxHeadingLevel: 3
 app_context:
   - m: application_details
     s: tokens
 topics:
+  - build
   - tokens
-  - authentication
   - oauth
 sdk: []
 languages:
@@ -22,17 +24,17 @@ audience: developers
 complexity: intermediate
 keywords:
   - access tokens
-  - JWT
+  - JWT claims
   - OAuth 2.0
-  - token claims
   - feature flags
   - permissions
-  - organization claims
+  - token refresh
+  - token expiry
   - billing trial
-updated: 2026-04-13
+updated: 2026-08-31
 featured: false
 deprecated: false
-ai_summary: Comprehensive guide to Kinde access tokens including standard JWT claims, Kinde-specific claims like organization codes and feature flags, and token behavior during refresh operations.
+ai_summary: "Reference for Kinde access tokens as JWTs used to authenticate users and pass authorization data to APIs. Documents an example token and standard claims including aud, azp, exp, iat, iss, jti, scp, and sub, plus custom claims via Properties. Covers Kinde-specific claims: org_code, feature_flags with type and value short codes, permissions, billing trial fields has_trial_period and trial_expires_on, external provider ID, and Microsoft Entra ID ext_ claims. Explains refresh_token grant behavior: Kinde may return an unexpired access token unless it was revoked, the user signed out via logout, or the token expired. FAQ covers removing claims with the user token generation workflow, the default 24-hour access token lifetime, and that revocation, session end, or user deletion does not shorten already-issued access tokens. Intended for developers implementing authorization."
 ---
 
 Access tokens are a secure way of authenticating users and passing information about a user to a system.
@@ -145,22 +147,25 @@ Access tokens are a secure way of authenticating users and passing information a
 
   ```
 
-## Can I remove claims to reduce token size?
+## Behaviour of Access Tokens on refresh
 
-Yes. Kinde automatically populates the access token with claims like `permissions`, `feature_flags`, and `org_code`. If your app handles this data another way — or you want to keep JWTs small and free of client-readable claims — you can strip any of these from the token at generation time using the [user token generation workflow](/workflows/example-workflows/user-token-generation/#reduce-token-size).
+When you use the `refresh_token` grant to refresh an access token, Kinde will return an existing access token if that existing access token is not expired. You will get a completely new access token if one (or more) of the following conditions are met:
 
-The workflow fires whenever a token is issued and gives you full control over what goes into the final token. You can also use it to retrieve data from the [Kinde Management API](/kinde-apis/management/) server-side instead of embedding it in the JWT.
+- You revoke your existing access token
+- Your user has signed out of their session, and your application has called the logout function in Kinde
+- Your existing access token has expired.
 
-## How long does an access token last?
 
-Access tokens have a default lifetime of **24 hours (86,400 seconds)**. You can change this in **Settings > Environment > Applications > [your app] > Tokens**. Kinde does not recommend extending the access token lifetime beyond 1 day, as access tokens are the most exposed token type and a longer lifetime increases the window of risk if one is compromised.
+## FAQ
 
-For a comparison of all token default lifetimes, see [Configure token and session expiry](/build/tokens/configure-tokens/).
+### Can I remove claims to reduce token size?
 
-## Behaviour of Access Tokens on refresh
+Yes. Kinde automatically populates the access token with claims like `permissions`, `feature_flags`, and `org_code`. If your app handles this data another way — or you want to keep JWTs small and free of client-readable claims — you can strip any of these from the token at generation time using the **user token generation workflow** - see [Remove claims](/workflows/workflow-tutorials/customize-token-with-workflow/#remove-claims).
 
-When you use the `refresh_token` grant to refresh an access token, Kinde will return an existing access token if that existing access token is not expired. You will get a completely new access token if one (or more) of the following conditions are met:
+The workflow fires whenever a token is issued and gives you full control over what goes into the final token. You can also use it to retrieve data from the [Kinde Management API](/kinde-apis/management/) server-side instead of embedding it in the JWT.
 
-- You revoke your existing access token
-- Your user has signed out of their session, and your application has called the logout function in Kinde
-- Your existing access token has expired.
+### How long does an access token last?
+
+Access tokens have a default lifetime of **24 hours (86,400 seconds)**. You can change this in **Settings > Environment > Applications > [your app] > Tokens**. Kinde does not recommend extending the access token lifetime beyond 1 day, as access tokens are the most exposed token type and a longer lifetime increases the window of risk if one is compromised.
+
+For a comparison of all token default lifetimes, see [Configure token and session expiry](/build/tokens/configure-tokens/). Note that revoking a token, ending a session, or deleting a user does not shorten the lifetime of an access token that has already been issued — see [What revocation does and doesn't do](/build/tokens/configure-tokens/#what-revocation-does-and-doesnt-do).
@@ -1,7 +1,7 @@
 ---
 page_id: b5f45f88-93ff-4323-a57f-bfdc0b52878a
 title: Configure token and session expiry
-description: Comprehensive guide for configuring token and session expiry times including security best practices, token lifetime management, and risk mitigation strategies for different token types.
+description: "Configure Kinde token lifetimes, revoke sessions, and close the JWT access window after logout or user deletion"
 sidebar:
   order: 1
 relatedArticles:
@@ -15,9 +15,9 @@ app_context:
   - m: application_details
     s: tokens
 topics:
+  - build
   - tokens
   - security
-  - configuration
 sdk: []
 languages: []
 audience: developers
@@ -26,14 +26,15 @@ keywords:
   - token expiry
   - session timeout
   - token lifetime
-  - security
   - refresh tokens
   - access tokens
-  - ID tokens
-updated: 2026-04-03
+  - token revocation
+  - JWT validation
+  - token introspection
+updated: 2026-08-31
 featured: false
 deprecated: false
-ai_summary: Comprehensive guide for configuring token and session expiry times including security best practices, token lifetime management, and risk mitigation strategies for different token types.
+ai_summary: "Guide to configuring Kinde token and SSO session lifetimes per application. Lists default lifetimes: refresh token 15 days, access token 24 hours, and ID token 1 hour. Explains the role of ID, access, and refresh tokens and session inactivity timeout, plus security risks such as token theft and session hijacking. Includes dashboard steps to set expiry in seconds, optional client-specific refresh token cookies on a custom domain, and revoking tokens via POST /oauth2/revoke. Details what revocation does immediately (SSO session and refresh tokens) versus what it does not (already-issued access tokens remain valid until exp because APIs validate JWTs locally). Recommends shortening access token lifetime and using introspect only for high-value actions. Covers reuse detection, refresh token rotation, and revoking tokens after logout. Intended for developers configuring token security."
 ---
 
 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.
@@ -98,6 +99,36 @@ 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](https://docs.kinde.com/kinde-apis/frontend/#tag/oauth/post/oauth2/revoke).
 
+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](/authenticate/manage-authentication/session-management/#end-a-users-sessions-from-your-backend).
+
+## What revocation does and doesn't do
+
+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
+
+**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](/build/tokens/configure-tokens/#set-token-lifetimes) above.
+
+<Aside>
+
+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.
+
+</Aside>
+
+**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
 
 Tokens can be vulnerable to security breaches. Access tokens in particular contain sensitive information, and these tokens can be used to access systems.