Logout Session-Revocation Automation: A Session That Outlives the Decision to End It
Clearing a cookie is not the same action as ending a session
A browser's own session cookie and the actual, underlying session it represents on the server are two genuinely separate things, connected only by reference — deleting the cookie removes the browser's own ability to present that session, but does nothing whatsoever to the session's own validity as recorded on the server. For as long as the underlying token the cookie referenced remains valid there, anything else already holding a copy of it — another signed-in device, a token that had been copied, extracted, or intercepted at some earlier point — continues working exactly as before, completely unaffected by an action that, from the browser that took it, looked and felt like a complete, successful logout.
How the underlying problem shows up before you fix it
A logout or sign-out action calls the underlying authentication provider's own sign-out function with a `local` (or equivalently narrow) scope — a mode that clears only the current browser's own session state, explicitly NOT revoking the underlying token on the server.
The visible, local result of clicking logout — a redirect to the login screen, no further access from that specific browser — looks and feels identical to a genuine, complete session termination, giving no visual signal that anything broader failed to happen on the server side.
A session token that had already reached somewhere else — a second device signed into the same account, a token copied or intercepted through an entirely separate incident — remains fully valid and usable after the account holder deliberately logs out from their own primary browser, for as long as that token would have lasted on its own unrelated expiration schedule.
The gap is completely orthogonal to whether a session was ever actually stolen or misused — it exists purely in what the logout ACTION itself does, and is present even for an account that has never experienced any other security incident at all.
A security audit specifically distinguishing sign-out SCOPES (local vs. global, in the terminology of a common authentication provider) is what surfaces this class of gap — from the outside, a `local`-scope logout and a genuinely complete logout are visually and functionally indistinguishable to the person clicking the button.
Why a local-scope sign-out can look complete when it is not
Calling a sign-out function with its default or narrowest scope is often the first, most natural implementation choice — it is fast, requires no additional network round-trip beyond clearing local state, and produces the exact visible result a person expects when they click "Log out": they land back on the login screen, unable to continue browsing. Nothing about that visible outcome distinguishes a merely-local sign-out from a genuinely complete one, which is precisely what allows the narrower, weaker version to ship and remain unnoticed indefinitely — the gap only becomes meaningful for a scenario (a second device, a previously copied token) that ordinary use of the logout button, by design, never actually exercises or reveals.
How Centriu Helix made "log out" mean the session actually ends
A dedicated internal security audit of Centriu Helix (the same 2026-06-02 audit closing the error-log cross-tenant and login open-redirect findings described on this pillar's companion pages) specifically examined the module's logout action and found it called the underlying authentication provider's own sign-out function with a `local` scope — clearing the current browser's own cookie while leaving the actual, underlying refresh token on the authentication server completely untouched and fully valid for the remainder of its own, unrelated expiration window.
The fix changes the call to a `global` scope — the mode that genuinely revokes the refresh token on the authentication server itself, ending the real underlying session across the shared single-sign-on domain those tokens are valid for, rather than merely clearing the one browser's own local reference to it. A resilient fallback was added in the same change: if the network call performing that server-side revocation fails for any reason, the person is still redirected to the login screen regardless, rather than being left stuck on a logout action that never visibly completes — the local sign-out result is guaranteed either way, while the (now genuinely attempted) server-side revocation is the additional, correct behavior layered on top of it.
What is actually built today
Centriu Helix's logout action calls the authentication provider's sign-out function with a `global` scope, genuinely revoking the underlying refresh token on the server rather than only clearing the current browser's own local session state.
A revoked session is ended across the shared single-sign-on domain those tokens are valid for, not merely hidden from the one specific browser that initiated the logout action.
A network failure during the server-side revocation call no longer prevents the person from being redirected to the login screen — the local sign-out result completes regardless, with the revocation attempted as the correct additional behavior on top of it.
The identical `global`-scope pattern is documented, in the fix's own code comments, as already proven and applied in several of Centriu's other systems before being applied to Helix.
This fix was verified alongside, and shipped in the same production deployment as, this pillar's separate companion findings on the same 2026-06-02 Helix security audit.
A button that finally means what it says (illustrative framing of the actual confirmed mechanism)
Before the fix, clicking "Log out" on one device redirected that device's browser to the login screen, while a session already active on a second device — or a token that had been copied at some earlier point — continued working completely normally, entirely unaffected by that logout action. After the fix, the identical click on the first device genuinely revokes the underlying session on the server, ending it across the shared authentication domain regardless of how many other places that same token had already reached.
What changes operationally
Centriu Helix's logout action now genuinely revokes the underlying session on the authentication server, closing a gap where clicking "Log out" cleared only the current browser's own local cookie while leaving the actual session token fully valid anywhere else it had already reached — with a resilient fallback ensuring a network failure during revocation never leaves anyone stuck unable to complete the logout they requested.
When this is not the right fit
This automation covers specifically what happens when someone deliberately clicks Centriu Helix's own logout action — it does not address session theft, interception, or how a token might have reached a second location in the first place, which are separate concerns from whether a deliberate logout genuinely ends a session everywhere it is valid. It is also a distinct mechanism from this pillar's separate companion page on the same audit's login open-redirect finding, which concerns where a browser is sent AFTER signing in, not what happens when signing out.
Clearing a local cookie vs. revoking the underlying server-side token
Clearing only the current browser's own session cookie is the simpler, faster implementation, and it produces the exact visible result — a redirect to the login screen — that a person expects immediately after clicking logout, with no extra network round-trip required. It does not, however, touch the actual underlying session recorded on the server, leaving that session fully valid anywhere else it has already reached for as long as it would have lasted regardless. Revoking the token on the server itself is the only version of the two where the word "logout" describes something that has genuinely, verifiably happened — not merely something the one browser that clicked the button can no longer see.
Related systems
Main system: Centriu Helix.
What it does NOT do
- Does not change what happens while a session is still active and in normal use — this fix specifically concerns what happens at the moment someone deliberately logs out, not ongoing session behavior beforehand.
- Does not investigate or address how a session token might have reached a second device or been copied in the first place — that is a separate concern from whether a deliberate logout action genuinely revokes a session everywhere it is valid.
- Does not overlap with this pillar's separate companion page on the same audit's login open-redirect finding — that page concerns validating where a browser is redirected to AFTER signing in, an entirely different mechanism from what happens when signing out.
- Does not retroactively revoke any session that was already active and left un-terminated by a `local`-scope logout before this fix shipped — sessions active before the fix continue on their own original expiration schedule; the fix changes behavior for logout actions going forward.
- Does not add a new logout feature or button — the fix changes the scope parameter of an existing sign-out call that was already present and already being triggered by the existing logout action.
Security and governance
Centriu Helix's logout action now calls the authentication provider's sign-out function with a `global` scope, genuinely revoking the underlying refresh token on the server across the shared single-sign-on domain, with a resilient fallback ensuring a network failure during revocation never prevents the local logout from completing. Full detail on this module's session-management and security practices lives at /governanca and /iso.
Pricing and contracting
Available by monthly subscription, with tiered plans. Values and terms come from the official pricing table at /precos (Centriu's central source — never restated here).
Frequently asked questions
Did this bug mean logout did nothing at all?
No — logout still correctly cleared the current browser's own local session and redirected to the login screen. The gap was specifically that the underlying session token on the server remained valid and usable elsewhere, unaffected by that local action.
What is the practical difference between 'local' and 'global' sign-out scope?
A `local`-scope sign-out clears only the current browser's own session reference. A `global`-scope sign-out additionally revokes the actual underlying token on the authentication server, ending the real session across every place it is valid, not just the one browser that triggered it.
Was any specific account actually compromised by this gap?
The finding describes the mechanism itself, verified and closed as part of a dedicated internal security audit — it does not identify or claim a specific historical incident of misuse; a team needing that assessment would need its own dedicated review.
What happens now if the server-side revocation call fails due to a network problem?
The person is still redirected to the login screen regardless — the local sign-out result completes either way, with the server-side revocation attempted as the correct additional behavior layered on top, not a precondition for completing the visible logout.
Is this the same finding as the login redirect page on this site?
No — that page concerns validating where a browser is sent immediately AFTER a successful login; this page concerns whether a deliberate logout action actually revokes the underlying session on the server. Both come from the same 2026-06-02 Helix security audit but are independent mechanisms.
What does Centriu Helix cost?
It is sold by subscription with a published starting price — exact current values are on the central pricing page.
See how Centriu Helix makes "log out" actually end the session
Reach our commercial team directly, or leave your details below — we'll follow up with guidance for your case.