Gestion des sessions

In OpenID Connect (OIDC), users often interact with multiple applications (Relying Parties) through a single identity provider (OP).

When a user logs out from one service, they usually expect to be logged out from all connected services. This is where OIDC Session Management comes in!

Imagine you log into Google, then use Google Login for YouTube and Gmail. If you log out of YouTube, should you still be logged into Gmail?

Synchronizing session status across different applications and the identity provider is a complex challenge in distributed systems.

To help RPs track a user's session with the OP, OIDC introduces the session_state parameter.

This value, along with the iss (issuer) URL, allows RPs to monitor for changes in the user's session at the OpenID Provider.

Front-channel logout is one technique for achieving Single Logout (SLO).

It relies on the user's browser to communicate logout requests to all active Relying Parties (RPs).

When a user logs out from the OP, the OP redirects the user's browser to a special logout endpoint.

This endpoint then uses hidden iframes or image requests to load specific "logout URLs" from each registered RP, signaling them to terminate their local session.

Front-channel logout is simple to implement for RPs, as it doesn't require complex server-side logic.

• Pros: Easy setup, leverages browser.
• Cons: Can be unreliable. Browser restrictions (like third-party cookie blocking) or network issues can prevent RPs from receiving the logout signal.

Back-channel logout offers a more robust and reliable way to achieve Single Logout.

Instead of relying on the browser, it uses direct server-to-server communication between the OpenID Provider and the Relying Parties.

When a user logs out, the OP sends a special Logout Token directly to the RP's pre-registered back-channel logout URI.

Upon receiving this token, the RP validates it and then terminates the user's local session.

A Logout Token is a JSON Web Token (JWT) issued by the OP.

It contains claims like iss (issuer), sub (subject), aud (audience), and a special events claim indicating a back-channel logout event. It also includes a sid (session ID) to identify the specific session to terminate.

Choosing between front-channel and back-channel depends on your needs:

• Front-channel: Simpler, browser-dependent, less reliable for critical applications.
• Back-channel: More robust, server-to-server, requires dedicated RP endpoint, better for security-sensitive contexts.

Great work! You've explored how OpenID Connect handles session management.

We covered the importance of session synchronization, the browser-based front-channel logout, and the more robust server-to-server back-channel logout using Logout Tokens.

Understanding these mechanisms is key to building secure and user-friendly OIDC applications.