Open Authorization (OAuth)

Expanded Definition

OAuth, short for Open Authorization, is a delegation protocol used to let an application act on behalf of a user or another system without collecting the underlying password. In NHI environments, it is most often encountered through app-to-app authorisation, API access, and third-party integrations that exchange scoped tokens for limited access. The practical boundary matters: OAuth governs delegated access, while authentication answers who or what the caller is. That distinction is well established in IETF guidance and is also central to how NIST Cybersecurity Framework 2.0 frames access control and governance.

Definitions vary across vendors when OAuth is discussed alongside OpenID Connect, service accounts, or secrets managers, so teams should avoid using the term as shorthand for “secure login” or “API permissioning” in general. OAuth can support strong governance, but only when scopes are tightly bounded, tokens are rotated or revoked promptly, and third-party access is continuously reviewed. The most common misapplication is treating an OAuth grant like a one-time setup step, which occurs when organisations fail to review the app’s continued access after deployment.

Examples and Use Cases

Implementing OAuth rigorously often introduces lifecycle and visibility overhead, requiring organisations to weigh faster integration against the cost of monitoring every consented app, token, and scope change.

• Delegating a SaaS integration to read a mailbox or calendar without sharing the user’s password, while limiting the scope to only the required data set.
• Connecting an internal workflow tool to a CRM so a service can create records, but not export full customer data or modify admin settings.
• Authorising a partner application through a consent screen, then periodically reviewing whether that partner still needs access after the business relationship changes.
• Investigating a breach path like the Salesloft OAuth token breach, where token theft turns a delegated connection into a data-access channel.
• Comparing OAuth with a separate identity layer such as OpenID Connect, which is why NIST Cybersecurity Framework 2.0 is often used to structure governance, not to define the protocol itself.

In practice, OAuth is also used to reduce password sharing between tools, but that benefit only holds when consent, token scope, and application ownership are tracked throughout the credential lifecycle.

Why It Matters in NHI Security

OAuth matters because it often becomes the control plane for third-party and machine-to-machine access, which means a weak grant can expose far more than a single user session. In NHI programs, OAuth apps are frequently the hidden route into SaaS platforms, CI/CD systems, and collaboration tools where service accounts, API keys, and tokens accumulate faster than teams can review them. That is why our research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, making it difficult to see which integrations still have live access and which ones are effectively orphaned.

This risk shows up clearly in incidents such as the Dropbox Sign breach, where delegated application access and token handling become part of the incident path. In a Zero Trust model, OAuth should support least privilege, short-lived access, and explicit revocation, not permanent trust. Teams also need to align OAuth governance with operational controls in NIST Cybersecurity Framework 2.0, especially around access review, monitoring, and response. Organisations typically encounter OAuth risk only after an integration is abused, at which point token revocation and app deauthorisation become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• OAuth Connected App
• How should teams secure MCP authorization beyond OAuth scopes?
• Should organisations adopt open standards for authorization now?
• Orphaned OAuth Authorization