Session management

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, without affecting other organizations.

Manage SSO session behaviors and policies

Link to this section

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.

   

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 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

Link to this section

• 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.

End a user’s sessions from your backend

Link to this section

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 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.

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.

FAQ

Link to this section

What counts as activity for SSO session inactivity?

Link to this section

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?

Link to this section

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).