IdP Logout in an SPA

Logout procedure in a Single Page Application (SPA) involves several crucial steps. First, the user confirms the logout action. The application then proceeds to instruct all embedded child applications to log themselves out, waiting until they report completion before moving on. This phase is critical as it ensures all applications associated with the user's session are terminated.

Next, the application reads the ID token from its token store. If no ID token is found, the process skips the IdP round trip, directly clearing local state and navigating to the shared logout landing page. This route is taken to avoid unnecessary communication with the Identity Provider (IdP) and to streamline the logout process.

The logout navigation is directed to the IdP's end-session endpoint, accompanied by two parameters: the current ID token (id_token_hint) and the app's own logout-callback route. The ID token is crucial as it identifies the session to be ended. Simultaneously, the logout-callback route handles the cleanup process.

Upon reaching the IdP's end-session endpoint, the IdP destroys its session cookie and redirects the browser back to the registered callback route. This redirection is pivotal as it initiates the cleanup process on the application side.

The cleanup process involves reading the ID token one last time from storage, clearing local and session storage (with an explicit allow-listed key prefix), and finally redirecting to the shared logout landing page. This step ensures that any remnants of the user's session are removed from the application's storage, maintaining a clean slate post logout.

The sequence of these steps is deliberate. Child applications are logged out first to ensure any unfinished operations within them are properly terminated, preventing data loss. Tokens are cleared last, ensuring the ID token is available twice: once as an id_token_hint for the IdP and again as a hint for the downstream landing page. This two-step usage ensures that session termination is accurately communicated to both the IdP and the application post logout.

Understanding the order of these steps is vital. The IdP session is truly ended only upon a top-level navigation, as background processes or hidden IFrames cannot reliably clear session cookies under third-party cookie restrictions. A full-page redirect serves as a reliable method to end the IdP session.

The process is contingent upon several preconditions at the IdP. The logout-callback URI must be registered as a post-logout redirect URI, failing which the user gets stranded at the IdP. The end-session endpoint requires the presence of a valid and unexpired ID token; otherwise, it may display an interactive prompt asking which session to terminate, disrupting the user experience.

Potential failure modes include the IdP failing to redirect back due to unregistered URI, rejected hint, or user closing the tab. In such scenarios, local tokens are left behind, and the application may still appear signed in until the tokens expire. Other failure modes include the absence of an ID token at step 2 or the callback route failing to render, both of which must be handled as best-effort measures or logged appropriately.

Additionally, the order of steps ensures other considerations. The IdP session is ended only upon a top-level navigation, as background processes cannot reliably clear session cookies under third-party cookie restrictions. Preconditions at the IdP require the logout-callback URI to be registered, and the end-session endpoint to accept the id_token_hint without rejecting it.

In conclusion, a well-structured logout procedure in an SPA encompasses confirming the logout intent, instructing all child applications to log out first, reading the ID token, navigating to the IdP's end-session endpoint with necessary parameters, and ensuring a thorough cleanup process. By adhering to this sequence and considering potential failure modes, applications can provide a seamless logout experience for users while maintaining security and integrity.