Session management with Okta

Note: This document is written for Okta Classic Engine. If you are using Okta Identity Engine, contact your Okta account team for guidance or ask on our forum. See Identify your Okta solution to determine your Okta version.

An Identity Provider (IdP) is a service that stores and manages digital identities. Okta is an IdP service that stores and verifies user identities. Okta provides a federated sign-in service so that a user can access multiple apps with a single set of sign-in credentials. A session is a group of user interactions with a resource, such as an IdP service or an app, for a given amount of time. When you use Okta as your IdP, there are two types of sessions that you need to consider for managing the user experience: the IdP session and the app session.

IdP session

Okta creates the IdP session after the user is authenticated using their credentials and various MFA options. After authentication, the user is able to access apps within the managed identity org by using Single Sign-On (SSO), all within the scope of the IdP session. The session uses cookies to store user information to track and facilitate interactions between the user and the org. The IdP session is active until the user signs out of the org or when the session expires, based on the policies defined in the org.

Application session

The app creates the app session (also known as a local session) after the user is authenticated. This session uses cookies to store user app-specific information to track and facilitate interactions between the user and the app. The time frame of the app session depends on the nature of the app:

• A shorter and restrictive session is required for privileged access apps, such as an e-commerce site where users make payments.
• A longer and less restrictive session is typical for non-privileged access apps, such as a catalog site where users browse listed items. The session for these apps can remain active even when the user navigates away, closes the browser tab or website, or closes the mobile app.

Identity management admins and app developers need to collaborate on how to manage the IdP session with the app sessions. Successful collaboration produces an optimal user experience with security, device, and app privileged access in mind. For example, collaboration includes balancing terminating sessions and redirecting the user to re-authenticate for security purposes. Or collaboration includes extending the session or silently reauthenticating with a new session for a frictionless user experience.

Examples of sign-out experiences

Privileged access use case

For privileged access apps, such as an e-commerce payment app, securing sensitive user information is paramount and app sessions need to be tightly restricted. App sessions are short lived and inactivity timeouts are in the minutes for these types of apps. Developers need to employ best practices and end app sessions when they're no longer required. If the app session is terminated, the user must be redirected to the IdP to re-authenticate back into the app for a new session. If there's no active IdP session during the redirect, the user is prompted to sign in to the IdP for a new IdP session, and then through SSO is signed in to the app for a new app session.

Non-privileged access use case

For non-privileged access apps, such as a loyalty program catalog, sessions can be active for a longer time. App developers don't need to implement session timeouts to restrict access. This is especially true for mobile apps where you want your users to have a seamless and frictionless user experience. In this scenario, the app session can outlive the IdP session. App sessions can still track user interactions without the IdP session. However, when the user signs out and ends the app session without the IdP session, the user is redirected to the IdP sign-in page and must authenticate with the IdP to gain access to the app, as before.

Terminate sessions

Local logout

Local logout is the act of signing the user out of the app and terminating the app session. The user IdP session is still active, and other app sessions aren't affected by terminating a specific local app session. The app manages local logout. If the user wants to access the app again, the user is automatically authenticated through the active IdP session into the app, and the app creates a session for the user.

See Sign users out for a guide to implement local logout with Okta.

Single Logout (SLO)

Single logout is the act of signing the user out of the IdP and signing out of all the apps with the same IdP credentials. This results in ending the IdP session and all the associated app sessions for the user.

Note: App-initiated single logout is also known as Service Provider-initiated (SP-initiated) single logout (SLO).

Okta supports app-initiated single logout, where the user signs out of both an app and the Okta IdP to end both the app and IdP sessions. However, other app sessions for the user might persist without the IdP session, depending on the restrictive nature of the apps.

For non-privileged access apps, the user can still access the app within the scope of the app session. For example, a user might browse through a catalog of vacation experiences and add one to their cart. When the user attempts to check out, the app might enforce a privileged access workflow and force the user to re-authenticate with Okta before it secures an IdP session. For privileged access apps with short-lived sessions, the user is typically redirected to re-authenticate with Okta to start a new IdP session and an app session.

See the Sign users out guide (located within the Sign users in section of developer.okta.com) for a guide to implement Okta sign out in Okta Classic Engine. For Admin Console app-initiated SLO configuration, see Configure Single Logout in app integrations (opens new window).

Note: To configure SLO in Okta Identity Engine, see Configure Single Logout.

Explore Okta quickstart sample apps for sample code with non-privileged access implementations.