OAuth grants and refresh tokens can remain valid independently of the original password, which means an attacker can keep accessing services without reusing the stolen credential. That is why password resets alone do not close the access path. Teams need grant review and token revocation as part of the response.
Why This Matters for Security Teams
OAuth grants are not simple password substitutes. They are delegated authorisation artefacts that can outlive the password used to create them, so a reset may remove one entry point while leaving another intact. That is why password-only response playbooks routinely miss the real persistence layer. NHI Mgmt Group’s research shows only 5.7% of organisations have full visibility into their service accounts, which is a strong signal that opaque grants and tokens often go unmanaged alongside other NHIs.
This becomes operationally important wherever users connect SaaS apps, automation tools, or AI assistants through OAuth consent. The issue is not just stolen credentials, but the continued validity of refresh tokens, app consents, and third-party access paths. Standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls reinforce the need for access revocation and monitoring, but the practical gap is that many teams still treat password changes as containment. In practice, many security teams encounter OAuth persistence only after an attacker has already used the grant to re-enter the environment.
Recent incident reporting in the Salesloft OAuth token breach and the Klue OAuth Supply Chain Breach shows how delegated access can remain valuable to an attacker even after the original login path is closed.
How It Works in Practice
OAuth persistence happens because the grant and its tokens are separate from the user’s password lifecycle. When a user consents to an app, the application may receive a refresh token or other long-lived authorisation that can be exchanged for new access tokens without the password being re-entered. If the identity provider does not explicitly revoke the grant, the attacker can keep using that delegated access until token expiry or consent revocation.
Operationally, response needs to include more than password reset. Teams should review the connected app, the scopes granted, the token age, the refresh token status, and whether the app is first-party or third-party. Where the platform supports it, revoke the grant at the identity provider, invalidate active sessions, and rotate any downstream API keys the app may have stored. The State of Non-Human Identity Security report is especially relevant here because it highlights the visibility gap across third-party OAuth apps. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports revocation, monitoring, and access review as ongoing control activities rather than one-time events.
- Revoke the OAuth grant, not just the password.
- Invalidate refresh tokens and active sessions where the platform allows it.
- Inspect app scopes for overreach and remove unnecessary permissions.
- Check for linked secrets, API keys, and service account credentials stored by the application.
- Log the consent source, tenant, and application owner for later review.
This guidance breaks down when the identity platform lacks per-grant revocation or when the OAuth app has already exchanged delegated access for separate long-lived secrets in the target system.
Common Variations and Edge Cases
Tighter grant control often increases operational overhead, requiring organisations to balance faster incident containment against user friction and app breakage. That tradeoff is especially visible in SaaS-heavy environments, where employees connect many tools and administrators hesitate to revoke broadly because business workflows may fail.
There is no universal standard for this yet, but current guidance suggests treating high-risk OAuth consents differently from ordinary user sessions. For example, a low-risk internal app may warrant normal review cadence, while a third-party integration with broad mailbox or file scopes should be subject to immediate grant inspection after any account compromise. The Dropbox Sign breach and Microsoft OAuth Breach both illustrate why scoped access still requires lifecycle control.
Another edge case is delegated access used by automation or AI agents. Those workloads may legitimately need persistent access, but best practice is evolving toward short-lived tokens, explicit owner approval, and continuous review rather than indefinite trust. If an app can silently refresh access in the background, the risk is not the password history but the grant itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle control for non-human credentials and token revocation. |
| NIST CSF 2.0 | PR.AA-05 | Identity proofing and access lifecycle management fit grant persistence risk. |
| NIST SP 800-63 | Digital identity guidance supports session and authenticator revocation after compromise. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust requires continuous verification of delegated access, not one-time trust. |
| NIST AI RMF | AI RMF is relevant where OAuth grants support autonomous tools or agents. |
Treat password resets as incomplete until all delegated sessions and tokens are revoked.
Related resources from NHI Mgmt Group
- Why do OAuth applications create persistent access risk even after off-boarding?
- Why do OAuth and OpenID Connect integrations create IAM risk even when they reduce password use?
- Why do non-human identities create more risk than many human accounts?
- Why do non-human identities create more remediation risk than many human accounts?
