What should log out mean across a customer’s devices?

Write down the promise first

A customer who presses Log out expects that the current device can no longer open private account pages. That expectation is easy to describe and surprisingly easy to implement incompletely. Removing the account name from a page or redirecting to a welcome screen changes appearance; it does not by itself prove the old session is invalid. Define the promise in terms of a later request: if the browser presents the old session secret to a protected endpoint, the server rejects it and asks for authentication again. Include downloads, order history and account changes in that test, not only the dashboard. NIST describes session continuity as possession of a secret issued after authentication, while OWASP advises explicit server-side invalidation on logout. Those sources provide a useful design basis, though a small shop must still choose its own user experience and risk policy.

Decide whether the button means 'log out this device' or 'log out all devices'. Both can be useful, but they are different promises. A customer closing a session on a shared counter computer may want to keep their own phone signed in. Someone who suspects that a device is missing may need a separate 'sign out everywhere' action. Use words that match the actual scope and display a clear completion message. If an action revokes all sessions, explain that other devices will need to sign in again; if it only revokes this one, avoid implying global protection. The same account may have multiple browser profiles, phones and tablets. Treat each active session as an identifiable record for operational purposes without exposing the secret itself in the interface or logs.

End access on the server and in the browser

For a server-managed session, invalidate its identifier in the server's session store when the customer logs out. Clear the corresponding browser cookie as part of the response, and make protected routes consult the server state on every request. Clearing a cookie alone cannot invalidate a copied identifier that someone else still holds. Conversely, server invalidation without clearing the browser state can leave a confusing interface or an old token repeatedly sent until rejection. The server must also enforce idle and overall expiry; a browser-close event is not a reliable security boundary because browsers may restore sessions and mobile applications may not fire a closing event. A logout design therefore needs a server action, a browser cleanup action and a test of a subsequent protected request.

For token-based applications, document which token grants immediate access and whether a refresh token can issue another one. Revoking only a visible browser token may leave a refresh path able to recreate access. A short-lived access token may remain usable until expiry unless the system checks revocation or changes its validation state; explain that behavior before promising instant global logout. Choose a design that meets the actual risk: server-backed sessions can be invalidated directly, while self-contained tokens often need a revocation strategy and bounded lifetime. Avoid storing long-lived bearer session secrets in browser local storage merely because it simplifies frontend code. NIST specifically warns against insecure locations such as HTML local storage for session secrets because script injection can expose them. Keep these details in the technical design, with customer copy describing only the effect they can rely on.

Handle tabs, devices and identity providers

Several tabs on the same browser profile usually share the same session cookie. After logout in one tab, another tab might still display an already rendered account page until it refreshes. That stale view is a privacy concern on a shared screen even if the server already rejects new requests. Clear sensitive in-memory state, prevent private responses being served from inappropriate shared caches, and make other tabs update their visible state when feasible. The decisive test remains a protected request from the second tab; the account must not return private data. Explain the difference between an old image still visible on a screen and a server continuing to authorize access, and address both in the release checklist.

A customer may sign in through a separate identity provider, such as an organization's single sign-on. NIST states that the provider's session and the relying application's session are independent: ending one does not automatically end the other. A customer who logs out of the shop may still be signed in at the identity provider and return through a fresh assertion; that does not prove the shop's old session survived. Conversely, a provider logout does not necessarily terminate the shop session. Map which party owns each session and test the intended sequence. If the interface offers a broader federated logout, verify the particular integration actually performs it. Do not promise 'all accounts everywhere' based only on a redirect to the provider's page.

Test a realistic lost-device decision

Use a hypothetical customer with a laptop at home and a phone that may have been left in a taxi. First, record a harmless protected request on both devices while they are legitimately signed in. On the laptop, select 'sign out this device' and verify that the laptop's old session fails while the phone remains active if that is the documented policy. Sign in again on the laptop, then select 'sign out all devices'. The same protected request must fail from both old sessions, including from a tab left open on the phone. If the system uses access and refresh tokens, test whether refresh can recreate an authorized session. This is a controlled test account scenario, not a suggestion to send any customer's live credentials to a tester.

The completion screen should say what happened and what the customer can do next. If all-device revocation is not immediate under the chosen token design, give a truthful description of the window and prioritize a safer design for sensitive changes. Do not claim that changing a password always ends every existing session; make that a separate verified rule. A password reset, suspected compromise and voluntary logout are different triggers, even if the system deliberately reuses the same revocation mechanism. Check the account's support process so staff can explain what 'this device' and 'all devices' mean without making guarantees that the implementation cannot meet. Keep the message short enough to be useful at the moment of action.

Account-change events deserve an explicit matrix. Decide whether changing a password, adding a new sign-in method or reporting a compromised device should revoke only the current session, all sessions, or a selected device. Give the customer an explanation before a disruptive action and a confirmation afterward. A support agent should see the policy, not an undocumented assumption. For a high-risk event, the business may choose broader revocation than for an ordinary end-of-visit logout; this is a policy choice to document and test. Keep an audit trail of the revocation event and its scope without recording bearer secrets. The customer should have a route back into the account through the normal verified sign-in process.

Make logout a repeatable acceptance test

Before release, test current-tab logout, another tab in the same profile, another browser, another device, idle expiry and overall expiry. Test direct entry to a private URL after logout and a download URL that was open before logout. Include the mobile application if one exists, because closing an app is not equivalent to pressing a server-backed logout action. Check that cookies use appropriate secure attributes and that protected responses do not leak through an unintended cache. Do not record session secrets in a support ticket or analytics event. The test record should contain the scenario, time, expected scope and accept or reject result, not the credential value. A failure on one route means the public promise is still incomplete.

Finally, assign an owner to review session behavior whenever sign-in architecture changes. A new identity provider, an added mobile app or a switch from server sessions to self-contained tokens can invalidate old test assumptions. Recheck customer wording against the implementation after each such change. NIST and OWASP describe security principles and mechanisms, but they do not certify a particular shop's logout button; the business earns confidence through its own repeatable request-level checks. The practical next action is to write down the two supported logout scopes, use a test account across two devices, and refuse to label either scope complete until protected routes reject the old credentials as promised.

Also plan the failure path. If the logout request cannot reach the server, showing a reassuring completion screen would be misleading. Tell the customer the action did not complete, offer a retry, and avoid leaving a private screen unattended while the result is unknown. If the application queues actions offline, do not represent a queued logout as server revocation. On reconnection, confirm the server accepted it and make the UI reflect that state. Support staff need an escalation route for a customer who has lost a device and cannot use the account interface. That route should authenticate the requester and trigger the documented revocation process without asking for a password in a support message. Test the failure wording as carefully as the happy path.