OIDC session management

What is OIDC session management#

OpenID Connect (OIDC) is a simple identity layer built on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on the authentication performed by the authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner.

OIDC is designed to be easy to use and implement, with a focus on simplicity and flexibility. It is widely used for single sign-on (SSO) and identity verification in web applications, mobile apps, and APIs.

Understanding authentication status and session management in OIDC is crucial. This article explains how OIDC sessions and user authentication status are managed in the context of interactions between the Identity Provider (IdP) and Relying Party (RP) or Service Provider (SP).

This article includes several key terms.

• Identity Provider (IdP): The service that stores and authenticates user identities.
• Service Provider (SP) or Relaying Party (RP): A web application or service that provides services to users and relies on the IdP for user authentication.
• Sign-in session or Authentication session: The session that is established when a user logs in to the IdP.
• Grant: The centralized user authentication and authorization information that is generated and managed by the IdP.
• Single Sign-On (SSO): A session and user authentication service that permits a user to use one set of login credentials (e.g., name and password) to access multiple applications.

How does OIDC authentication flow work#

To better understand OIDC session and user authentication status management, let's briefly review the OIDC authentication flow for a web application:

1. The user accesses the web application (RP).
2. The RP redirects the user to the OIDC provider (IdP) for authentication.
3. The OIDC provider checks the user's sign-in session status. If no session exists or the session has expired, the user is prompted to sign in.
4. The user interacts with the sign-in page to get authenticated.
5. The sign-in page submits the interaction result to the OIDC provider.
6. The OIDC provider creates a new sign-in session and authentication grant for the user.
7. The OIDC provider redirects the user back to the RP with an authentication code (Authorization Code flow).
8. The RP receives the authentication code and exchanges it for tokens to access user information.

What is RP sign-in session management#

A sign-in session is established when a user logs in to the IdP. This session is used to track the user's authentication status at the IdP. The session typically includes information such as the user's identity, authentication time, and session expiration time. It is created when the user fist logs in and is maintained until the user logs out or the session expires.

A session cookie will be securely set in the user's browser to maintain the session state. The session cookie is used to identify the user's session and authenticate the user for subsequent authentication requests. This cookie is typically set with the HttpOnly and Secure flags to prevent client-side access and ensure secure communication.

One session for single RP#

For each RP that the user accesses from different devices or browsers, a separate user sign-in session will be established. This means that the user's authentication status is maintained separately for each RP. If the user logs out from one RP, the user will still be authenticated at other RPs until the session expires or the user logs out from all RPs.

Centralized session for multiple RPs#

This centralized session management also allows the IdP to maintain a consistent authentication state across multiple RPs as long as the user's session is active and the authentication requests come from the same user agent (device/browser). This mechanism enables SSO capabilities, where the user can access multiple RPs without having to log in again.

Client-side authentication status#

In OIDC, the client application (RP) relies on the IdP issued tokens to verify the user's identity and authentication or authorization status. The "sign-in session" at the client-side is maintained by the tokens issued by the IdP.

• ID Token: A short-lived token that contains user information and is used to verify the authenticated user's identity.
• Access Token: A token that grants access to protected resources on behalf of the user. The lifetime of the access token can be short-lived or long-lived, depending on the configuration. Client applications may rely on the access token's validity to determine the user's authentication status. If the access token is expired or cleared, the user may be considered as "signed out" or "unauthenticated" and need to re-authenticate.
• Refresh Token: If the offline_access scope is requested and granted, the client application may receive a refresh token. It provides a means to extend the user's authentication status without requiring the user to re-authenticate. The client application can use the refresh token to obtain a new access token when the current access token expires. As long as the refresh token is valid, the user's authentication status can be maintained without the need for user interaction.

The combination of these tokens allows the client application to maintain the user's authentication status and access protected resources on behalf of the user. The client application need to securely store these tokens and manage their lifecycle. (E.g. For SPA applications, the tokens can be stored in the browser's local storage or session storage. For web applications, the tokens can be stored in the server-side session data or cookies.)

OIDC sign-out mechanisms#

The sign-out process in OIDC is a multi-faced concept due to the involvement of both centralized IdP managed sign-in sessions and distributed client-side tokens.

Clear tokens and local session at the client side#

To sign out or revoke a user's authentication status at the client side is relatively straightforward. The client application can remove stored tokens (ID token, access token, and refresh token) from the user's browser or memory. This action effectively invalidates the user’s authentication status on the client side.

For web applications that manage their own user sign-in sessions, additional steps may be necessary. These include clearing the session cookie and any session data (such as tokens issued by the Identity Provider, or IdP) to ensure the user is fully signed out.

Clear centralized sign-in session at the IdP#

The IdP maintains a centralized sign-in session for each user. As long as this session is active, the user may be automatically re-authenticated even if client-side tokens have been cleared, allowing new tokens to be issued to the client application without requiring further interaction with the IdP.

To fully sign out a user from the IdP, the client application (RP) can initiate a sign-out request to the IdP. The application (RP) should redirect the user to the IdP's end-session endpoint to terminate the sign-in session can clear session cookies. This ensures a complete sign-out across all applications (RPs) sharing a same centralized session. Once the sign-in session is terminated, whenever the IdP receives an token request from any linked RPs that share the same session, the IdP will prompt the user to re-authenticate.

OIDC back-channel logout#

In some cases, when a user signs out from one application (RP), they may also want to be automatically signed out from all other applications (RPs) without any additional user interaction. This can be accomplished using the back-channel logout mechanism.

When the IdP receives a sign-out request from an RP, it not only clears the sign-in session but also sends a back-channel logout notification to all RPs use the same session and have a registered back-channel logout endpoint

When the RPs receive the back-channel logout notification, they can perform the necessary actions to clear the user's session and tokens, ensuring that the user is fully signed out from all applications.