Skip to main content

OIDC Frontchannel Logout Lifecycle

This document explains the technical details of the OIDC Frontchannel Logout implementation in Framework M, covering the interaction between the Identity Provider (IdP), the backend web adapter (BFF), and local session store management.

1. The Challenge of Federated Sessions​

In a federated architecture, users log in using a single identity provider (IdP) which issues tokens to multiple client applications. However, logging out from one client application does not automatically invalidate the user's session in other client applications, leading to orphaned local sessions (security vulnerabilities).

To coordinate session invalidation across all clients, the OpenID Connect (OIDC) specification defines Frontchannel Logout.

2. Frontchannel Logout Mechanics​

OpenID Connect Frontchannel Logout relies on the browser to propagate logout requests.

Sequence of Events​

  1. The user clicks "Logout" in Client A (or directly at the central IdP).
  2. The IdP invalidates the user's central session.
  3. The IdP renders a hidden HTML page containing an <iframe> for each registered client application's frontchannel logout URI.
  4. The user's browser loads the iframe, sending a GET request to Framework M's frontchannel logout callback: /api/v1/auth/oauth/<provider-key>/logout/frontchannel
  5. The request includes the user's session identifier (contained within the browser cookies sent along with the iframe request).
  6. Framework M's web adapter intercepts this request, locates the matching local session inside the SessionStore, invalidates it, and clears the local session cookies.
+----------+             +-----------------+             +-------------+
|  User    |             |  Central IdP    |             | Framework M |
+----+-----+             +--------+--------+             +------+------+
     |                            |                             |
     | 1. Log out                 |                             |
     +--------------------------->|                             |
     |                            | 2. Invalidate IdP session   |
     |                            |    and render iframe        |
     |<---------------------------+                             |
     |                            |                             |
     | 3. GET /logout/frontchannel (iframe request with cookies)|
     +--------------------------------------------------------->|
     |                                                          | 4. Delete local
     |                                                          |    session from
     |                                                          |    SessionStore
     |                                                          |

3. BFF Session Invalidation & Cookie Controls​

Because Framework M standard web adapter runs in Backend-For-Frontend (BFF) Cookie Mode, the browser relies on HTTP-only, secure, same-site session cookies for authentication.

When a frontchannel logout request is processed:

  • The web adapter looks up the active session identifier from the incoming request cookies.
  • If a session is found, it calls: 
    await session_store.delete(session_id)
  • It returns a response that sets the session cookie's expiration to the past (max-age=0), instructing the browser to delete the cookie: 
    Set-Cookie: session_id=; Max-Age=0; Expires=Thu, 01 Jan 1970 00:00:00 GMT; Path=/; HttpOnly; Secure; SameSite=Lax

This ensures that even if the user navigates back to the application, their browser no longer holds a valid session cookie, preventing unauthorized access.