A standing OAuth grant is a persistent authorization that lets an application act on a user's behalf without repeated approval. In security terms, it behaves like a reusable credential, so its scope, duration, and ownership need lifecycle controls just like any other privileged access artifact.
Expanded Definition
A standing OAuth grant is a long-lived authorization that lets an app continue acting for a user or service without fresh consent each time. In NHI practice, it is best understood as a reusable access artifact, not just a convenience feature.
Definitions vary across vendors on where the boundary sits between an oauth token, a refresh token, and the underlying grant, but the operational risk is consistent: if the grant survives beyond the business need, the application can keep pulling data or taking actions long after intent has changed. That is why standing OAuth grants belong in lifecycle governance, scope review, and offboarding controls, not only in authentication workflows. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces access control, monitoring, and recovery as ongoing responsibilities rather than one-time setup tasks.
The most common misapplication is treating a standing OAuth grant like a harmless login state, which occurs when teams assume user consent alone is enough to justify indefinite application access.
Examples and Use Cases
Implementing standing OAuth grants rigorously often introduces friction for users and admins, requiring organisations to weigh convenience and automation against revocation discipline and visibility.
- A sales productivity app keeps access to a mailbox after the employee leaves, so the grant must be revoked during offboarding rather than left to expire eventually.
- An integration platform reads calendar events on behalf of users, but its standing grant should be reviewed when scopes expand beyond the original business purpose.
- A help desk tool can create tickets and read profile data continuously, which is useful until excessive permissions turn the grant into a broad standing privilege.
- After the Salesloft OAuth token breach, many organisations reassessed which SaaS integrations retained durable access without clear ownership or expiry.
- In the Dropbox Sign breach, token and integration trust assumptions showed how a persistent grant can become a hidden pathway to data exposure when monitoring is weak.
For implementation design, the relevant question is not whether OAuth is secure in the abstract, but whether each standing grant has an owner, a purpose, and a revocation trigger. That framing aligns well with NIST Cybersecurity Framework 2.0 expectations for continuous governance.
Why It Matters in NHI Security
Standing OAuth grants are important because they often outlive the human who approved them. Once they become invisible to the business owner, they function like quiet privileged access, especially in SaaS ecosystems where third-party apps multiply quickly. NHI Mgmt Group research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes persistent grants especially hard to inventory and control.
That visibility gap matters because standing grants can bypass the usual signals that security teams rely on for account review. A user may be deleted, yet the connected app still has access; a password may be rotated, yet the grant still authorizes API calls; a role may change, yet the scope remains unchanged. This is why standing OAuth grants should be managed with the same discipline as other NHI artifacts, including ownership, monitoring, and revocation workflows. The issue is not limited to access depth. It also affects incident response, because responders need to know which integrations can continue operating after a credential event. Guidance in NIST Cybersecurity Framework 2.0 and the lessons reflected in the Salesloft OAuth token breach both point to the same operational need: continuous control over durable access.
Organisations typically encounter the consequences only after a user departs, an integration is abused, or a breach investigation reveals that an old grant was still active, at which point standing OAuth grants become operationally unavoidable to address.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers risky secret and token handling that includes durable OAuth grants. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access control applies to persistent app authorizations. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | Zero Trust requires continuous verification, not implicit trust in old grants. |
Inventory standing grants, assign owners, and revoke anything without an active business purpose.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
