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. 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.
Application 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 application header. The policies of the application govern the settings of the application 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 application directly. They're granted a single Okta session and a session for each application that they access.

The user attempts to access a protected application directly, not through Okta.
Access Gateway intercepts the request and redirects it to Okta, which performs the SAML assertion.
The user's browser sends a SAML authentication request to Okta and signs in to the application. 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 application enhancements, such as header or cookie attributes.
3. Performs any required rewrites.
4. Proxies the request to a backing-protected resource.
A backing-protected web resource receives the request, creates an application session, and 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 application through their Okta dashboard. They're granted a single Okta session, and a session for each application they access.

The user signs in to Okta, and Okta creates an Okta session for them.
The user clicks an application tile in their Okta dashboard and is redirected to Access Gateway.
Access Gateway creates an Access Gateway session.
Access Gateway performs the following tasks:
1. Adds any required application enhancements, such as header or cookie attributes.
2. Performs any required rewrites.
3. Redirects to a backing-protected web resource.
A backing-protected web resource receives the request, creates application 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 application 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 application and Access Gateway simultaneously. Universal Logout doesn't sign the user out of Okta.