What front-channel logout can and cannot end in an OIDC session

What front-channel logout can and cannot end in an OIDC session Front-channel logout gives an OpenID Provider a browser-mediated way to tell relying parties that an OpenID Connect session has ended. It does not give the provider a reliable way to erase every application state. Teams that treat the redirect as proof of global logout can leave server-side sessions, access tokens and local caches active. How the flow works The provider sends logout requests through the User Agent to each relying party's frontchannel_logout_uri. The request carries an iss value and, when the client registers frontchannel_logout_session_required, a sid value that identifies the provider session. The relying party must verify the issuer and match the session identifier to its own records before removing the corresponding local session. This is a notification path, not an administrative control channel. The provider cannot confirm that the browser reached the relying party, that the relying party processed the request, or that the user's session was removed. Where the boundary weakens The browser must be active for the request to arrive. Privacy settings, partitioning rules, extensions and content blockers may interfere with the cross-site frames used to deliver logout requests. A closed browser can also skip the interaction entirely. A valid sid does not invalidate every credential issued during the session. Access tokens may remain valid until expiry, refresh tokens may have a separate revocation model, and downstream services may have their own sessions. The relying party also needs a durable mapping from sid to every local session it created. If that mapping is incomplete, the logout handler has nothing useful to remove. The endpoint must reject a request with the wrong issuer or an unknown session identifier. Logging those rejections helps distinguish malformed provider traffic from delayed or replayed requests. It also prevents a random caller from using the endpoint as an unauthenticated session-removal primitive. Controls that close the gaps Use front-channel logout as one layer. Keep local sessions short, revoke refresh tokens at the authorization server when the application requires immediate termination, and give high-value services a server-to-server revocation path. Back-channel logout can complement the browser flow because it does not depend on the user's browser remaining open. Test the workflow with the browser closed, with third-party frames blocked and with one relying party temporarily unavailable. Confirm that the provider session still expires, that the application's local session is removed when the callback arrives, and that the access-token lifetime limits the remaining window. Record which sessions were found, which were removed and which required operator action. The useful question is not whether logout returned HTTP 200. It is which state can still authenticate after the event and whether the remaining lifetime matches the organization's policy. References OpenID Connect Front-Channel Logout 1.0 OpenID Connect Back-Channel Logout 1.0