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

Because the attacker may not be relying on the password at all. If access was already granted to a third-party app, the token or consent grant can remain valid until it is revoked, expired, or reclassified. In that case, the compromise survives the reset and continues through delegated authorisation.

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.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP API Security Top 10	API2 — Broken Authentication	OAuth resets fail when token-based auth remains valid.
Recommendation — Revoke tokens and sessions, not just passwords, after delegated-access compromise.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Token, secret, and credential lifecycle control is central to reset and revocation.
	AC-2 — Account Management	OAuth grants and connected apps need lifecycle governance and deprovisioning.
	AU-6 — Audit Record Review, Analysis, and Reporting	Token use and consent changes need reviewable logs for containment.
Recommendation — Rotate, revoke, and expire authenticators and tokens on compromise. Review and remove stale delegated access during incident response. Review logs for token use, consent events, and session continuation after reset.
OWASP ASVS	V10 — OAuth and OIDC	The question is about OAuth delegation, tokens, and authorization flows.
Recommendation — Validate token revocation, consent handling, and audience restrictions in OAuth flows.

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.