Differences Between OpenID Connect Application Sessions and Okta Sessions
Last Updated:
Overview
Logging users in and out of an OpenID Connect (OIDC) application involves two types of sessions: one at the Identity Provider and one within the application. Understanding the differences between an OIDC application session and an Okta session clarifies how they relate to each other and how to end them properly.
Applies To
- Okta Identity Engine (OIE)
- Okta Classic Engine
- OpenID Connect (OIDC)
- Implicit (or Hybrid) flow
- Authorization Code flow
Solution
How does the login process work?
To log in to an OIDC application, a user must first complete primary authentication with Okta. The user verifies their credentials, such as a username, password, and any other required authenticators. Once authentication completes, Okta creates an Okta session. Okta tracks this session in the user's browser via a session cookie set on the Okta domain. A valid Okta session allows users to log into Okta and access any assigned applications. When a user logs into an OIDC application, the application receives tokens from Okta as evidence of successful authentication.
At this point, the application creates and tracks an application session for the user. For example, when using an Okta JavaScript SDK (AuthJS, React, Angular, or Vue), the application stores the user's tokens in the tokenManager. The user remains authenticated as long as valid tokens exist within the token manager.
Two methods exist for keeping users logged in.
Administrators can keep users logged into the application by requesting the offline access scope to receive a refresh token or by initiating a new OIDC flow.
- Request the
offline_accessscope to receive a Refresh Token. This is the preferred option when using the Authorization Code flow. - Initiate a new OIDC flow. This is the only option when using the Implicit flow.
How do refresh tokens interact with the Okta session?
While the user requires an Okta session to log into the application originally and receive a refresh token, an active Okta session is not required to obtain new tokens for the user as long as a refresh token exists. The application uses the refresh token to keep the user's application session alive until the refresh token expires or the administrator revokes it. This process prevents the application from prompting the user to log back in or redirecting the user back to Okta.
Silent or redirect-based token renewals require a valid Okta session.
If the application does not receive a refresh token from Okta, the application must make a new /authorize request to Okta to obtain new tokens for the user. Applications only receive a refresh token when using the Authorization Code or Resource Owner Password Grant flows. The application performs this request silently, as described in the Renew access and ID tokens with SPAs document, or via a full browser redirect. In both cases, the Okta session and the associated cookie must remain valid for the user on the browser. If the session is invalid, Okta prompts the user to re-authenticate, or the request fails if the application uses prompt=none.
How is the logout process handled?
When logging users out of the OIDC application, the application must close the application session. For example, when using an Okta JavaScript SDK, the application clears the tokens out of the token manager. The application must also revoke the access and refresh tokens.
Additionally, administrators might want to end the user's Okta session. In OIDC, the application redirects users to the End Session Endpoint /logout to end the Okta session. When using an Okta SDK, Okta provides methods designed to end either or both types of session. Review the SDK documentation or the Okta guides for more information.
