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.

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.

Manage SSO session behaviors and policies

Link to this section

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.

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