Why Logging Out All Devices Isn’t Enough: Proper Session Revocation Steps

Access to a user account is not a single token; it is composed of three independent credential systems. A browser session stores a short‑lived cookie that authenticates the current device. An OAuth grant is a long‑lived authorization that a third‑party application receives after the user consents to “Sign in with X”. Legacy API tokens are static keys issued to scripts or developer apps and can be used without any interactive login. Because each system lives in a different store, revoking one does not automatically invalidate the others, which is why an attacker can retain access after a “log out of all devices” action.

Credential types and their lifecycles

• Browser sessions – created when a user signs in via a web UI; they expire after inactivity or when the user explicitly logs out.
• OAuth grants – issued to third‑party apps (e.g., scheduling tools, analytics dashboards); they remain valid until the user revokes the grant in the connected‑apps list.
• Legacy API tokens – static secrets stored in developer portals or configuration files; they persist until manually deleted or rotated.

Practical examples

• A user logs into the web console on a laptop; the session cookie expires after 30 minutes of inactivity.
• The same user authorizes a CI/CD service via OAuth; the service can push code changes for weeks without re‑authenticating.
• An internal automation script uses an API token saved in a server’s environment file; the token works even if the user changes their password.

Recommended revocation order

1. Identify and revoke unwanted third‑party OAuth grants in the account’s connected‑applications list.
2. Delete or rotate any legacy API tokens found in the developer portal or application settings.
3. Log out all browser sessions via the security settings.
4. Change the account password as a final step, ensuring no active grant can expose the new credential.

Post‑revocation verification

• Review login history for unknown devices or locations after revocation.
• Confirm recovery email and phone number have not been altered.
• Audit recent content (posts, messages, configuration changes) for unauthorized activity.
• Regenerate two‑factor authentication recovery codes and invalidate any previously issued codes.

Following this systematic approach aligns with security best practices such as NIST SP 800‑63 (authentication and lifecycle management) and helps ensure that no single credential type can keep an account accessible after an incident.

Access to a cloud‑based account is not a single credential; it consists of three distinct mechanisms that persist independently:

• OAuth grants to third‑party applications – long‑lived authorizations stored in the platform’s connected‑apps list.
• Legacy API tokens – static keys used by scripts or developer tools, often managed in a developer portal.
• Browser session cookies – short‑term tokens that expire when a user signs out on a device.

Because each mechanism can survive the revocation of another, remediation must follow a deterministic order that reduces the attack surface before the password is changed. Changing the password first would leave any still‑valid OAuth grant or API token able to act on the new credentials, defeating the purpose of the password reset.

1. Remove unknown third‑party apps. Navigate to the connected‑applications page in the account settings. Identify entries that are unfamiliar or no longer needed, then revoke their access. This immediately cuts read/write permissions for those services.

   Example: An analytics dashboard added during a short‑term project may still appear in the list; revoking it prevents the dashboard from pulling data even if the underlying session expires later.

2. Revoke legacy API tokens. In the developer portal, delete or rotate any static tokens. All scripts, automation jobs, or third‑party deletion tools that rely on those tokens will stop functioning.

   Example: A nightly backup script using a hard‑coded token must be updated with a newly generated token after revocation.

3. Log out all browser sessions. Use the “log out of all devices” action in security settings. This clears session cookies on every device, forcing a fresh authentication flow.

4. Change the account password. Perform the password update after steps 1‑3 so that no lingering grant can expose the new secret.

5. Review two‑factor authentication (2FA) methods. Verify recovery email, phone number, and regenerate backup codes. Ensure that no attacker has replaced recovery options, a common post‑compromise tactic.

After completing the ordered revocation, follow the four verification checks recommended by NIST SP 800‑63B: review login history, confirm recovery contacts, audit recent content changes, and regenerate 2FA backup codes. This aligns with SOC 2 and ISO 27001 requirements for access control and incident response.

After revoking all credential types—browser sessions, OAuth grants, and API tokens—an account may still contain artifacts that an attacker could exploit or that indicate prior misuse. The revocation process itself does not reveal what actions were performed while access was active, so a systematic post‑revocation audit is required.

Essential post‑revocation checks

1. Review login history

   Examine the account‑activity log for device identifiers, IP ranges, or timestamps that you cannot associate with legitimate use. Pay special attention to entries that appear after the revocation event; new logins indicate that a credential (e.g., an OAuth grant) remained valid.

   Example: A security analyst notices a login from an unfamiliar city two days after logging out all devices. This suggests an OAuth token that was not revoked.

2. Verify recovery email and phone number

   Attackers often replace recovery contact methods before the victim changes the password, rendering the new password ineffective. Confirm that the listed email address and telephone number belong to the account owner and have not been altered.

   Example: The account’s recovery email now points to a personal alias the user never created; the analyst updates it back to the corporate address.

3. Audit published content and direct messages

   Check posts, profile fields, and private messages for modifications that were not authored by the legitimate user. Unauthorized changes can damage reputation or leak sensitive data.

   • Review recent status updates for unfamiliar language.
   • Inspect follower/following lists for unexpected connections.
   • Search message threads for outbound communications containing confidential information.

   Example: A user discovers a series of tweets promoting a phishing site that were posted during the breach window.

4. Regenerate two‑factor recovery codes

   Static recovery codes act as a back‑door to the second‑factor mechanism. If an attacker captured a previous set, they can bypass MFA even after the password is changed. Issue a fresh set of codes and invalidate the old ones.

   Example: After revocation, the security team generates new TOTP recovery codes and distributes them via an encrypted channel, then deletes any screenshots of the prior codes from cloud storage.

Performing these four checks restores confidence that the account is no longer vulnerable and provides evidence for incident‑response reporting, aligning with best‑practice frameworks such as NIST SP 800‑53 and ISO 27001, which require verification of account integrity after a security event.

Enterprise accounts typically rely on three independent credential stores: browser‑based session cookies, OAuth grants issued to third‑party applications, and long‑lived API tokens or developer keys. Each store persists beyond a simple password change, so an attacker who has captured any one of them can continue to act on the account even after the password is reset. Understanding this separation is a prerequisite for deciding when a full revocation pass—clearing all three stores—is required.

Standards such as NIST SP 800‑63 and ISO 27001 define “credential lifecycle management” as a control that must address all authentication artifacts, not just passwords. When any artifact is suspected of compromise, the control recommends a comprehensive revocation to re‑establish a trusted state.

Scenarios that justify a complete revocation

• Unknown sign‑in alerts: A login from an IP address, device type, or geographic region that cannot be explained indicates a possible session hijack.
• Lost or un‑wiped devices: Phones, laptops, or tablets that were sent for repair or sold without a secure wipe may still hold active session cookies or stored OAuth tokens.
• Forgotten authorisations: Over time, teams accumulate OAuth grants to SaaS tools or internal services that are no longer documented, making it difficult to assess their scope.
• Leaked credential lists: If an email address or username appears in a public breach, any associated API tokens or developer keys are assumed compromised, even if no suspicious activity is yet visible.

When any of these conditions arise, follow a disciplined revocation order to avoid re‑exposing the new password:

1. Revoke third‑party OAuth grants from the connected‑applications list.
2. Invalidate all legacy API tokens and developer keys.
3. Log out browser sessions on every device via the “log out of all devices” action.
4. Change the account password as the final step.
5. Review and rotate two‑factor recovery codes and confirm recovery email/phone numbers.

After revocation, verify that the incident has been contained by checking login history for new entries, confirming that recovery methods have not been altered, and reviewing any published content for unauthorized changes. This systematic approach aligns with SOC 2’s “Logical Access Controls” requirement and ensures that all potential attack vectors are neutralised before normal operations resume.

Modern platforms separate authentication into at least three distinct credential stores: browser sessions, OAuth grants to third‑party applications, and API tokens (or developer keys). A password change only affects the password hash; it does not invalidate the other stores. Consequently, an attacker who retains a valid OAuth grant or API token can continue to read or write data even after the user’s password is reset.

Consider a typical incident workflow:

1. Identify an unknown device in the account‑activity log.
2. Press “log out of all devices” and change the password.
3. Observe continued suspicious activity a week later.

The persistence occurs because the “log out of all devices” button revokes only browser sessions. OAuth grants and API tokens remain live until they are explicitly revoked.

Correct revocation order

Revocation must proceed from the widest scope to the narrowest, and the password change should be the last step. This prevents a still‑valid grant from exposing the new password the same way it exposed the old one.

• Third‑party apps – remove unknown entries from the connected‑applications list in account settings.
• Legacy API tokens – delete tokens in the developer portal or application‑management area.
• Browser sessions – use the platform’s “log out of all devices” action.
• Account password – change after all tokens are revoked.
• Two‑factor methods – review and regenerate recovery codes and MFA devices.

Forensic implications of ordering mistakes

If the password is changed before revoking OAuth grants, the attacker can use the existing grant to retrieve the new password via token‑exchange endpoints, effectively nullifying the reset. Moreover, revoking tokens first and then changing the password can overwrite logs that record the original compromise, making it harder to prove the breach to auditors or to satisfy compliance frameworks such as NIST SP 800‑63 or ISO 27001.

Practical checks after revocation include:

• Review login history for post‑revocation entries.
• Confirm recovery email and phone number remain under your control.
• Audit recent content changes (posts, profile edits, API‑driven actions).
• Regenerate and securely store new MFA recovery codes.

Following this disciplined order preserves forensic evidence while ensuring that all avenues of access are truly closed.