Why do password resets not stop OAuth-based account takeover?

Why password resets do not invalidate OAuth access

Password resets only change one authentication factor, usually the password used to log in interactively. OAuth-based takeover can survive because the attacker is using a previously issued access token, refresh token, or consent grant, not the password itself. If the delegated permission remains valid, the attacker keeps access until the token is revoked, expires, or is otherwise invalidated.

That is why OAuth 2.0 Authorization Framework matters here: authorization is a separate trust path from password-based authentication. A reset may block future password use, but it does not automatically undo already granted delegated access.

What actually preserves the compromise after the reset

The persistence mechanism is the grant, not the password. In practice, a malicious app or compromised client can continue acting through a valid refresh token, a long-lived access token in some implementations, or a retained consent record that still authorises token issuance. The account may look “fixed” from a login perspective while the third-party pathway remains open.

This is why OAuth security guidance focuses on token theft, sender-constrained tokens, audience restriction, and revocation behaviour. RFC 9700: Best Current Practice for OAuth 2.0 Security, RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP), and RFC 8707: Resource Indicators for OAuth 2.0 all address different ways to reduce replay and over-broad token use.

In other words, a password reset changes who can authenticate to the account, but it does not necessarily change what already-authorised software can do on the account’s behalf.

How to think about response and recovery

The right recovery action is to treat the event as delegated-access compromise, not just credential compromise. That means reviewing connected applications, revoking suspicious grants, checking refresh-token issuance, and confirming whether the identity provider supports session and consent invalidation across all linked apps.

Attackers also exploit this gap because it gives them durable access with less user-visible disruption. Consent phishing, malicious OAuth apps, and token theft are attractive precisely because password resets often leave the attacker’s path intact until the grant itself is removed. NHIMG’s Microsoft verified publisher OAuth phishing 2022 and Gitloker GitHub extortion campaign illustrate how consent abuse can persist after the victim notices a login problem.

Risk and Threat Considerations

OAuth-based compromise creates a blind spot because incident responders often focus on password hygiene while the attacker is operating through a separate delegated trust relationship. If refresh tokens, app consent, or persistent sessions are not revoked, the compromise can continue even after the account password is changed.

Failure mechanism: The attacker keeps using a valid token or consented application, so password rotation does not remove the active access path. This is especially dangerous when the granted scope is broad or the token can be refreshed without fresh user interaction.

Impact: Data theft, mailbox access, API abuse, and account persistence can continue after the reset, which delays containment and can make recovery look complete when it is not.

Practitioner Guidance

What to verify: Confirm whether the compromise involved password login, an OAuth grant, or both. If the user changed a password but did not revoke connected apps and sessions, the account should still be treated as exposed.

What to prioritise: Revoke third-party consents and refresh tokens first, then assess whether the attacker had mailbox, API, or admin-scoped access. Password rotation alone is only a partial response when delegated access exists.

What good looks like: Recovery procedures should include a clear way to enumerate trusted apps, invalidate sessions, and confirm that token-based access was actually removed, not just presumed removed.

Practitioner takeaway: Password resets close one door, but OAuth compromise usually enters through another one, so containment must target the delegated grant, not only the credential.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they rely on password security alone to stop account takeover?
• Why do password managers still fail to stop account takeover in real environments?
• How should security teams reduce account takeover risk when remote and hybrid workers rely on password-based authentication?
• Why does password-based MFA still leave law firms exposed to account takeover and lost productivity?