This article explains the differences between an OpenID Connect (OIDC) application session and an Okta session, how they relate to each other, and how to end them.
- OpenID Connect
- Implicit (or Hybrid) flow
- Authorization Code flow
- Logging users in
- Logging users out
Logging users in and out of an OIDC application involves two types of sessions: one at the Identity Provider (Okta, in this case) and one within the application.
Login
In order to log in to an OIDC application, a user must first complete primary authentication with Okta, where the user will verify their credentials (username, password, and/or any other required authenticators). Once this is complete, the user will have an Okta Session, which Okta tracks in the user's browser via a session cookie set on the Okta domain.
A valid Okta session will allow users to log into Okta and access any of their assigned applications. When a user logs into an OIDC application, the application will receive tokens back from Okta as evidence of the user's successful authentication.
At this point, the application should create and track an application session for the user. For example, if using one of Okta's JavaScript SDKs (AuthJS, React, Angular, or Vue), the user's tokens will be stored in the tokenManager, and the user will be considered authenticated as long as there are valid tokens stored within it.
Keeping users logged in
In OIDC, there are two ways to keep the users logged into the application:
- Request the
offline_accessscope (preferred option when using Authorization Code flow) to receive a Refresh Token. - Initiate a new OIDC flow (only option when using Implicit flow).
Refresh Tokens and the Okta session
While the user needed an Okta session to log into the application originally (and receive their refresh token), an active Okta session is not required to get new tokens for the user as long as there is a refresh token. The refresh token is used to keep the user's application session alive (until the refresh token has expired or been revoked) without having to prompt the user to log back in or otherwise redirect the user back to Okta.
Silent or Redirect-based Token Renewals and the Okta session
If the application cannot or does not receive a refresh token back from Okta (it is possible to only receive a refresh token when using the Authorization Code or Resource Owner Password Grant flows), the application will need to make a new /authorize request to Okta to get new tokens for the user. This can be done "silently" (described in our Renew access and ID tokens with SPAs document) or via a full browser redirect. In both cases, the Okta session (and its cookie) must still be valid for the user on their browser. If it is not, the user will be prompted to re-authenticate, or the request may even fail (if prompt=none is used, see the link above).
Logout
When logging users out of the OIDC application, it is essential to ensure that the Application Session is closed (for example, in the example above regarding our JavaScript SDKs, which involves clearing the tokens out of tokenManager) and that their Access and Refresh Tokens are revoked.
In addition, it might be desired to end the user's Okta session. In OIDC, redirect users to the End Session Endpoint/logout, which will end their Okta session.
If using one of our SDKs, OKta has methods designed to end both or either type of session. Check out their docs or our guides for more information.
