Access Gateway and sessions
There are three session types used by Access Gateway:
- Okta session: When a end user logs into their Okta org and accesses an application, or when a request is redirected to an Okta org from Access Gateway, an Okta session is created. Okta sessions are managed in an Okta org and subject to the settings associated with that org. An Okta session is created when the user has been successfully authenticated within Okta. Okta Administrators can manage various session timeouts and other details.
- Access Gateway session: When a user requests access to a protected web resource, Access Gateway creates a session for the application request. Timeouts and other behaviors are application specific. See Advanced application settings for more information.
Note, an Access Gateway application session is created after a user has been successfully authenticated within their Okta org and only if they are allowed access to the underlying protected resource. - Application session: Application sessions are created after a user has been authenticated, has access to the protected resource within Access Gateway, and the request is redirected to underlying protected web resource.
The following user information is used when creating a session:
| Who | What | Description |
|---|---|---|
| Okta session |
|
The user can connect to and authenticate within Okta. Typically this involves a username/password and one or more additional MFA factors as required by the Okta Org. Once authenticated, application access requests result in the creation of an Okta session. Okta sessions are subject to the settings, policies and controls defined within the originating Okta org. |
| Access Gateway application specific session |
|
The user, as identified to Access Gateway by email address or other identifier, is a member of the group associated with the requested protected web resource. Once identified, Access Gateway creates an application specific session associated with the authenticated users request. The Access Gateway application setting is subject to the settings and policies associated with the application definition. See the Define application behaviors for details of managing application specific settings and behaviors. |
| Application session |
|
Access Gateway proxies the protected web resource request to the underling protected resource. Included with the request are header fields, cookies, and any other information required by the application. The application specific request are then provided to the application which creates and manages its own application specific header. See the documentation of the protected web application for details of the life cycle, timeout and other behaviors specific to the application session. |
Service provider-based flow
Any number of applications can be involved in a server provider-based flow. In the preceding diagram, these are represented by steps 6(ab), 7(ab), and 8(ab).
An end user has a single session at the Okta level.
At the Access Gateway and backing application level, there are as many sessions as there are applications being accessed.
The service provider-based flow consists of the following steps:
- User requests application access.
- Access Gateway intercepts the request and redirects to Okta for SAML assertion.
- User (browser) sends a SAML AuthN request to Okta and signs in following Okta policies. On success, Okta creates an Okta session.
- Okta generates a SAML assertion for Access Gateway.
- User (browser) presents the SAML assertion to Access Gateway. Access Gateway creates an Access Gateway session cookie.
- Access Gateway creates an Access Gateway session, adds any required application enhancements (for example, header or cookie attributes), performs any required rewrites and proxies 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 response.
Identity provider (Okta)-based flow
The IdP-based flow consists of the following steps:
- User logins to Okta. Okta creates an Okta session.
- User selects an application from the Okta dashboard and is redirected to Access Gateway. Access Gateway creates an Access Gateway session.
- Access Gateway adds any required application enhancements (for example, header or cookie attributes),
performs any required rewrites, and 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 require rewrites and returns response.
Understand session lifecycles
Each session has a distinct lifecycle.
- Each Okta org login has a single session, governed and controlled by the policies of the Okta org. These policies define session creation, time out, log out and invalidation.
- Each Access Gateway application has its own distinct session, governed and controlled by the associated application definition and associated behavior. See Define application behaviors.
Access Gateway sessions and high availability
Access Gateway doesn't share session information between instances in high availability clusters. When defining clusters that are front-ended by load balancers, session affinity (also known as sticky sessions) must be specified to ensure that subsequent requests are routed to the same Access Gateway instance.
- Each application session is governed by the policies of the application. See the application-specific documentation for more information.
Single and Universal Logout
Okta federated authentication supports Single Logout (SLO) and Universal Logout.
Using SLO, service provider-initiated flows can be configured to sign out of both the application and Okta sessions simultaneously. With SLO enabled, Access Gateway acts as the service provider and Okta as the identity provider. When an end user logs out of Access Gateway, they're also logged out of Okta.
Using Universal Logout, admins can configure flows to sign the user out of the apps they're signed into and Access Gateway when they sign out or when their session expires. Universal Logout doesn't sign the user out of Okta.
See Configure Single Logout in app integrations and Define application behaviors.