--
title: "Logging Out All Devices Did Not Log Them Out: Session Revocation Done Properly"
description: "Logging out of all devices clears one kind of credential. Browser sessions, OAuth grants to third party apps and legacy API tokens are three separate things, and access survives as long as any one of them is live. How to tell them apart, the order to revoke in, and what to re-check afterwards."
tags: ["security", "privacy", "twitter", "howto"]
canonical_url: https://digital-footprint-health.shop/blog/x-session-revocation-all-devices
An unfamiliar login shows up in your account activity. You go to settings, log out of all devices, change the password, and consider it closed. A week later there is another unfamiliar device in the list.
The reason is that access to an account is not one thing. It is at least three separate credential systems, and logging out of all devices touches exactly one of them.
Three credential systems, three different lifespans
Browser sessions are what the log-out-all-devices button handles. Each device holding a login carries a session credential with its own expiry. Revoking clears those, and the affected devices get asked to sign in again.
OAuth grants to third party apps are different. Anything you signed into with the platform's login, any scheduling tool, any analytics dashboard, holds a long lived grant. That grant is not a session. Logging out of all devices does not touch it, and revoking sessions does not revoke it.
API tokens and application keys are the third system. If you registered a developer application, ran a script, or used a third party deletion tool, there may be an access token and a secret sitting in that application's settings. A leaked token lets someone operate your account without visiting a login page at all. These are the most commonly forgotten, because people set them up once and never look again.
Revoking in the right order
The order is not arbitrary. Work from the widest scope down, and change the password last, otherwise a still-valid grant can expose the new password the same way it exposed the old one.
| Order | What to revoke | Where it lives | Effect |
|---|---|---|---|
| 1 | Third party apps you do not recognise or no longer use | The connected applications list in account settings | That app loses read and write access immediately |
| 2 | Legacy API tokens and developer apps | The application management area of the developer portal | Every script and tool using that token stops working |
| 3 | Browser sessions on all devices | Security settings, the log out of all devices action | Every device is signed out |
| 4 | Account password | Account settings | Do this alongside step 3 |
| 5 | Two factor method review | Security settings | Confirm recovery options were not replaced |
Step one is usually the hardest, because a connected apps list tends to show application names without describing what permissions each one holds. Auditing that list properly is its own exercise, and it is worth doing as a separate pass rather than in the middle of an incident.
Four checks that revocation does not cover
Revoking tells you nothing about what someone did while they had access, so the follow-up matters as much as the revocation.
Check login history. Look for devices or locations you cannot account for, and pay particular attention to entries dated after the revocation. New entries after you cut access are a different problem from old ones.
Verify contact methods. Confirm the recovery email and phone number on the account are still yours. A common pattern is for an attacker to swap the recovery address first, which means your new password accomplishes nothing.
Review published content and direct messages. Look for posts you did not write, changes to your bio, and follow or unfollow activity you did not perform.
Regenerate recovery codes. Issue a fresh set for your two factor method so the old ones stop working. If a screenshot of the previous set lives in a photo library or a cloud note, handle that too.
When a full revocation is worth doing
Running this monthly is unnecessary and it disrupts your own devices. These situations justify a complete pass.
A sign-in alert from a device you do not recognise, or a login entry you cannot explain.
A phone lost, sent for repair or sold, or a laptop replaced without a wipe.
You have moved between third party tools and cannot recall what you authorised.
An email address associated with the account was caught in a credential leak, even if nothing suspicious showed up at the time.
Why a password change alone is not enough
Changing the password invalidates sessions in some implementations and not others, and it does nothing to OAuth grants or API tokens at all. Someone holding a valid grant or a live token continues to operate the account after the password changes, which is why the symptom often looks like the password change did not work.
If you have confirmed someone else was in the account before you started revoking, change the order. Recovering control comes before cleanup, and the recovery steps differ depending on whether this was a takeover or a credential phish. Getting the order wrong can destroy the evidence you need to prove what happened.
Top comments (0)