Because the token is often a separate bearer credential with its own scope and lifetime. Changing the user password does not automatically remove every delegated grant already issued to third-party apps. If the token remains valid, an attacker can keep using it until the organisation explicitly revokes it or the token expires.
Why the password change does not kill the token
OAuth access and refresh tokens are issued as separate credentials, so a password reset usually changes only the primary login secret. The token can continue to work because the application has already been delegated access. That is why breach response has to treat the token, the grant, and the password as different control points.
In practice, the risk is not the password itself but the surviving authorisation path. A bearer token can present enough proof on its own to reach the protected service, even when the original user can no longer sign in with the old password. If the issuer does not revoke the grant, the attacker may retain access.
The underlying mechanics are defined by RFC 6749: The OAuth 2.0 Authorization Framework, which separates client credentials, grants, and tokens. That separation is useful for delegated access, but it also means a password change is not a universal revocation event unless the implementation explicitly ties session and token invalidation together.
What makes the token still usable after the account password changes?
Most OAuth flows issue tokens to an app after the user has approved access. From that point on, the app may hold its own access token, refresh token, or both. Those tokens can be scoped to specific APIs and can outlive the original sign-in event, so the attacker does not need to keep guessing the password once a valid token exists.
Refresh tokens are especially important because they can be exchanged for new access tokens without forcing the user back through interactive login. If the organisation only resets the password and leaves delegated grants untouched, the token chain can remain intact. That is why password rotation and token revocation are related but not identical actions.
Many real-world incidents follow this pattern. A stolen token often survives longer than the password compromise that led to it, which is why current OAuth guidance increasingly emphasises token binding, sender-constrained tokens, and revocation hygiene. RFC 9700: Best Current Practice for OAuth 2.0 Security is the clearest reference point for those protections.
For readers who want the broader identity model, NHIMG’s Ultimate Guide to NHIs, what are Non-Human Identities explains why tokens, service accounts, and application credentials are treated as separate access-bearing artefacts rather than as passwords alone.
What has to happen to actually remove the breach path?
To close the breach path, the organisation needs to revoke the delegated grant, invalidate refresh tokens where possible, and check whether the token was copied into another system or workflow. Password reset is still useful, but it is only one step. If the token was issued to a third-party app, the app consent and scope must be reviewed as well.
That is why OAuth incident response often focuses on grant inventory and revocation, not only on user password hygiene. A token with broad scopes can expose email, files, CRM data, or API functions even after the user account is technically “secured” again. Scope, audience, expiry, and revocation semantics all affect whether the compromise is truly over.
Where the token is used for machine-to-machine access or app-to-app delegation, the risk can persist even longer because no human password prompt is involved at runtime. In those cases, the token is the live credential, and the correct response is to rotate or revoke the credential itself, not just the human login that originally authorised it.
NHIMG’s OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful companion when you need to trace how scopes, grant types, and token lifetimes affect revocation behaviour.
Risk and Threat Considerations
Bearer tokens create a classic post-compromise persistence problem: once stolen, they can be replayed until expiry or revocation, even if the user has already changed the password. That means the attacker’s access path may survive the visible remediation step and continue silently against mail, SaaS, or API resources.
Failure mechanism: The organisation treats password change as full remediation, but the delegated OAuth grant, refresh token, or active access token remains valid and continues to authorise API calls.
Impact: The attacker keeps authorised access, which can extend data exfiltration, mailbox access, file access, or app abuse beyond the initial detection window.
For a practical incident example, NHIMG’s GitHub OAuth token breach 2022 and Salesloft OAuth token breach both show how stolen tokens can remain useful after the original login state has changed.
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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Tokens and refresh credentials need lifecycle control and revocation after compromise. |
| AC-20 — Use of External Information Systems | Third-party OAuth apps keep delegated access after password change unless governed. | |
| IA-9 — Service Identification and Authentication | OAuth tokens often secure app-to-app access where bearer credentials remain valid independently. | |
| Recommendation — Revoke and rotate the affected token material immediately after suspected compromise. Review and revoke external app access paths tied to the compromised account. Bind service-to-service access to strong authentication and rapid credential revocation. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen or unrevoked OAuth tokens let attackers continue authenticated API access. |
| API5 — Broken Function Level Authorization | A valid token may still expose functions or actions after password reset. | |
| Recommendation — Validate token revocation and token expiry handling in your API authentication flows. Verify that every token-bound action is still authorised after grant changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | OAuth tokens can persist past password changes when lifetimes and revocation are weak. |
| Recommendation — Shorten token lifetimes and enforce explicit revocation on compromise. | ||
Practitioner Guidance
What to verify: After a password reset, confirm whether the identity provider, the app, and the target API all support revocation of the specific token type in use. If refresh tokens or offline access were issued, verify that those grants were actually removed and not merely left to age out.
Decision rule: If the suspected compromise involved a third-party app or SaaS integration, treat grant revocation and scope review as mandatory response steps, not optional hardening. If the token can access production data, prioritise token invalidation and blast-radius reduction before deciding whether password compromise was the root cause.
Common mistake: Teams often rotate the password, close the incident ticket, and assume the account is clean. The better test is whether any live bearer credential still exists that can reach the same protected resource.
Practitioner takeaway: A password change protects the login, but it does not automatically revoke the delegated authority already handed to an OAuth token.
Related resources from NHI Mgmt Group
- Why do OAuth grants create persistence even after a password is changed?
- Why do OAuth grants create risk even after offboarding, password resets, or MFA re-enrollment?
- Why do OAuth tokens create risk even after the user logs out or leaves?
- Why do OAuth applications create persistent access risk even after off-boarding?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org