Persistent SSO
Keep users signed in between browser visits for an application.
Kinde · Const
Session management
Kinde session management configures application-level SSO cookie persistence and inactivity re-authentication. Backends can also terminate a user’s sessions through the Management API.
How it works
Kinde session management controls the SSO session associated with an application. Configure whether its cookie persists after browser closure and set an inactivity period, or revoke a user’s sessions from a backend through the Management API.
Syntax
DELETE /api/v1/users/{user_id}/sessionsParameters
| Name | Type | Description |
|---|---|---|
user_id | path parameter | The Kinde user identifier whose sessions should be ended. |
Authorization | Bearer token | An M2M access token authorized with delete:user_sessions. |
Returns
The page does not specify a response body or status for the session-deletion endpoint.
Key points
- A Kinde session represents the interval in which Kinde considers the user authenticated.
- Configure session behavior independently for each application.
- A persistent cookie preserves the Kinde session across browser closure.
- A non-persistent policy ends the session when the browser closes, subject to documented limitations.
- The default inactivity timeout is 86400 seconds, equivalent to one day.
- The Management API endpoint deletes a user's sessions on demand.
Common mistakes
- Application-level settings do not configure sessions managed independently by your application.
- The inactivity timeout must be entered in seconds, not minutes or hours.
- Backend session revocation requires an M2M application with the delete:user_sessions scope.
Example: End a user's sessions
curl -X DELETE "https://<your_kinde_domain>/api/v1/users/<user_id>/sessions" \
-H "Authorization: Bearer <m2m_access_token>"Use the Management API from a backend to end all sessions for a user.
When to use it
Inactivity-based re-authentication
Require users to authenticate again after inactivity.
Backend session revocation
Force sign-out across Kinde sessions after a security event.
Interview questions
QWhat does Kinde session management control?
Kinde session settings are configured per application in the dashboard. They control whether the SSO cookie persists after the browser closes and how long inactivity can continue before re-authentication is required.
Follow-up: How would you revoke sessions for one user? Use DELETE /api/v1/users/{user_id}/sessions from a backend with an M2M application granted delete:user_sessions.
QWhat is the difference between persistent and non-persistent SSO sessions?
Choose Persistent to keep the session active after browser closure, or Non-persistent to end it when the browser closes. The inactivity timeout defines when Kinde prompts the user to authenticate again.
Follow-up: What unit does the timeout use? Seconds; the documented default is 86400 seconds, which is one day.
QHow do you configure session behavior?
Session settings are managed per application through Settings > Environment > Applications. Open the application, choose Sessions, configure the SSO session policy and inactivity timeout, then save.
Follow-up: Does this configure an application's own session store? No. The page limits these settings to Kinde sessions, not sessions maintained by the application.
Related
SSO sessionsSSO session inactivity timeoutManagement APIM2M applicationdelete:user_sessions