Access Gateway and sessions

Access Gateway works with sessions to secure your protected resources.

Access Gateway uses the primary email address from the Okta org to create and identify the user session. For security reasons, Okta recommends that you never use the same primary email address in multiple user accounts. Instead, use a unique primary email address for each user account. This prevents all user accounts with the same primary email address in their profile from having their session terminated if any one of those users signs out, or if their session is terminated by Okta, such as when Universal Logout is enabled.

Session types and lifecycles

Access Gateway uses three session types depending on what the user accesses:

Okta session: Okta creates a session when the end user directly authenticates to an org or when Access Gateway redirects a request to the org. Admins can configure the conditions for these sessions in the Okta org.
Access Gateway session: Access Gateway creates this session after a user requests access to a protected app and Okta authenticates them. Admins manage these sessions in the Access Gateway Admin UI console. See Advanced application settings and Define application behaviors. See Configure advanced app settings, which also includes information on valid values and limits for session configuration. Access Gateway doesn't share session information between instances in high availability clusters. When you deploy load balancers in front of your cluster, you must specify session affinity (also known as sticky sessions). This ensures that subsequent requests are routed to the same Access Gateway instance.
App session: Access Gateway creates this session after Okta authenticates the user or when the request is redirected to the protected app. Access Gateway modifies the web request with header fields, cookies, and other required information, and then delivers it to the protected app. The resource then creates and manages its own app header. The policies of the app govern the settings of the app session.

Session flows

You can initiate sessions from Access Gateway or from Okta.

Access Gateway or service provider-based session flow

In this scenario, the end user accesses an app directly. They're granted a single Okta session and a session for each app that they access.

The user attempts to access a protected app directly, not through Okta.
Access Gateway intercepts the request and redirects it to Okta, which performs the Security Assertion Markup Language (SAML) assertion.
The user's browser sends a SAML authentication request to Okta and signs in to the app. If authentication is successful, Okta creates an Okta session.
Okta generates a SAML assertion for Access Gateway.
The user's browser presents the SAML assertion to Access Gateway. Access Gateway creates an Access Gateway session cookie.
Access Gateway performs the following tasks:
1. Creates an Access Gateway session.
2. Adds any required app enhancements, such as header or cookie attributes.
3. Performs any required rewrites.
4. Proxies the request to a back-end protected resource.
A back-end protected web resource receives the request, creates an app session, and then returns a response to Access Gateway.
Access Gateway performs any required rewrites and returns the response.

Okta or identity provider-based session flow

In this scenario, the end user accesses an app through their Okta dashboard. They're granted a single Okta session, and a session for each app they access.

The user signs in to Okta, and Okta creates an Okta session for them.
The user clicks an app tile in their End-User Dashboard and is redirected to Access Gateway.
Access Gateway creates an Access Gateway session.
Access Gateway performs the following tasks:
1. Adds any required app enhancements, such as header or cookie attributes.
2. Performs any required rewrites.
3. Redirects to a back-end protected web resource.
A back-end protected web resource receives the request, creates app sessions, and returns a response to Access Gateway.
Access Gateway performs any required rewrites and returns the response.

Single and Universal Logout

Okta federated authentication supports two types of logout flows:

Single Logout: You can use Single Logout (SLO) to sign out of both the app and Okta sessions simultaneously in service provider-initiated flows. When SLO is enabled, Access Gateway acts as the service provider and Okta acts as the Identity Provider.
Universal Logout: Admins can configure flows to sign the user out of the app and Access Gateway simultaneously. Universal Logout doesn't sign the user out of Okta.