Why 'log out all devices' leaves OAuth grants and API tokens alive

Logging out of every device is the standard reaction to a suspicious login, and according to a walkthrough published on dev.to, it is usually not enough. The author describes the familiar sequence: an unfamiliar device shows up in account activity, the user revokes all sessions, rotates the password, and the problem returns a week later. The explanation is structural. Access to an account rests on at least three distinct credential systems, and the log-out button addresses only the first.

Three credentials behind one button

Browser sessions are the layer the button is built for. Each signed-in device holds a session with its own expiry, and clearing them forces those devices back to a login screen.

OAuth grants are separate. Any third-party tool authenticated through the platform's login, such as schedulers or analytics dashboards, keeps a long-lived grant that outlives sessions. Revoking sessions does not revoke the grant, so the app keeps its read and write access.

API tokens and application keys form the third layer. Anyone who has registered a developer app, run a script, or connected a deletion tool may have an access token and secret sitting in application settings. The author calls these the most commonly forgotten credentials, because they are created once and never revisited, and a leaked token lets someone operate the account without a login page ever being involved.

The post uses X (formerly Twitter) as its running example, but the same split applies to any platform that supports connected apps and developer tokens.

The order to revoke in

The sequence is not arbitrary, the author argues: work from the widest scope down, and change the password last, because a still-active grant can compromise the new password the same way it compromised the old one.

The recommended order:

1. Disconnect third-party apps you do not recognise or no longer use, from the connected applications list in account settings.
2. Revoke legacy API tokens and developer apps in the developer portal's application management area.
3. Log out all browser sessions.
4. Change the password, alongside step three.
5. Review the two-factor setup and confirm recovery options were not replaced.

The first step is described as the hardest, since connected-app lists tend to show application names without explaining what permissions each one holds. The author suggests auditing that list as a separate exercise rather than in the middle of an incident.

What revocation does not tell you

Cutting access says nothing about what happened while an intruder had it, so the follow-up matters as much as the revocation. The post lists four checks:

• Login history: look for devices or locations you cannot account for, and pay particular attention to entries dated after the revocation. New entries after access was cut point to a different problem than old ones.
• Contact methods: confirm the recovery email and phone number are still yours. The author describes swapping the recovery address as a common first move by attackers, one that makes a password change accomplish nothing.
• Content and messages: check for posts you did not write, changes to your bio, and follow or unfollow activity you did not perform.
• Recovery codes: issue a fresh set for your two-factor method so the old ones stop working, and deal with any screenshot of the previous set sitting in a photo library or cloud note.

When a full pass is warranted

Monthly sweeps are unnecessary and disruptive to your own devices, according to the post. A complete pass is justified in four situations: a sign-in alert or login entry you cannot explain; a phone that was lost, repaired or sold, or a laptop replaced without a wipe; a move between third-party tools that leaves you unsure what you authorised; or the account's email address appearing in a credential leak, even if nothing suspicious showed up at the time.

There is one reversal: if you have confirmed someone else was in the account before you start revoking, regaining control comes before cleanup. The recovery steps differ depending on whether this was a takeover or a credential phish, and doing them in the wrong order can destroy the evidence needed to prove what happened.

Why it matters

Password rotation is the reflex response to account compromise, and this post explains why it so often appears to fail. Changing the password invalidates sessions in some implementations and not others, and it does nothing to OAuth grants or API tokens. Whoever holds a live grant or token keeps operating the account after the change, which produces the illusion of an ineffective password reset. For developers, the lesson is that a log-out-all-devices feature which does not surface, or at least link to, connected apps and API tokens gives users a false sense of closure. For users, it is that the security screen you can see is rarely the full list of credentials that open the account.