OAuth Tokens Explained: Why Changing Your Password Doesn't Kick the Attacker Out
OAuth is how you let one app access another without sharing a password. Here is what the tokens are, why they outlive your password, and why a connected app is its own standing identity.
When you click "Connect to Google" or "Allow this app to access your account," you're using OAuth. It's the machinery behind every integration, every "sign in with," every connected app. It's also widely misunderstood in one specific way that matters enormously for security: the access it grants does not live or die with your password.
What OAuth is for
OAuth solves a real problem: how do you let App B access your data in App A without handing App B your App A password? Giving away your password would be total and unrevocable. OAuth replaces that with delegated, scoped, revocable access. You authenticate to App A yourself, App A asks "do you want to let App B read your calendar?", you consent, and App B receives a token — not your password — that grants exactly that access.
The tokens
Two kinds matter:
- Access token. A bearer credential App B presents to App A's API to act on your behalf, within the scope you granted. Like a session token, possession equals authorization — whoever holds it can use it. It's usually short-lived.
- Refresh token. A longer-lived credential App B uses to obtain new access tokens when the old ones expire, without bothering you again. This is what lets an integration keep working for months silently.
The grant is recorded on App A's side as a standing authorization: "App B is allowed to do X for this user." That authorization persists until it's revoked or expires — independently of your login sessions.
Why your password reset doesn't help
Here's the part people get wrong. When you suspect compromise, your instinct is to change your password. For a stolen session, that helps. For a stolen or malicious OAuth grant, it usually does nothing.
The reason is that the OAuth token was never tied to your password. It represents a separate, delegated authorization that you (or an attacker impersonating you) granted to an application. Changing your password doesn't revoke an app's token, because the app doesn't authenticate with your password — it authenticates with its token. The connected app keeps its access straight through your password reset, your new MFA enrolment, everything. To actually cut it off, you have to revoke the grant — remove the app from your connected-apps list, or invalidate its tokens server-side.
This is why "I changed my password, I'm safe now" is often false. If an attacker got a malicious app authorized, or stole a legitimate integration's tokens, your password was never in the loop.
A connected app is a non-human identity
The deeper point: every OAuth grant creates a standing, token-based identity that isn't a person. It doesn't have a password to change or a phone for MFA. It won't trip impossible-travel alerts, because apps don't travel. It just holds an authorization and uses it. This is great when the app is legitimate and well-behaved. It's dangerous because these grants accumulate — dozens or hundreds per account across an organization — and almost no one inventories them, scopes them tightly, or watches them the way they watch human logins.
So the two ways this goes wrong are: a user is tricked into authorizing a malicious app (the consent itself is the attack), or a legitimate app's tokens are stolen from the vendor that holds them. In both cases the result is a standing identity with API access that no human credential touches.
What to actually do
- Audit consent. Restrict who can authorize new connected apps; require admin approval or allow-list them, so a user can't grant an arbitrary app broad access.
- Inventory grants. Keep a list of connected apps, their scopes, and their owners. You can't revoke what you can't see.
- Scope tightly. An app that needs to read one calendar should not hold access to your entire mailbox.
- Revoke, don't just reset. When responding to compromise, revoke OAuth grants and invalidate tokens — changing the password is not enough.
- Monitor app behavior. A new high-permission grant, or an app suddenly pulling bulk data, is a high-signal event if anyone's watching non-human identities.
The takeaway
OAuth trades your password for scoped, delegated tokens — which is safer in normal use and surprising in a breach, because those tokens are a separate identity that your password reset can't touch. The control that matters isn't your password; it's governing, scoping, and revoking the standing app authorizations that quietly pile up behind every account.