A delegated access model where a third party handles the OAuth flow, token storage, or refresh logic for an application. The app relies on the broker to obtain usable tokens, which reduces implementation burden but creates a separate governance boundary that still needs inventory, review, and revocation.
Expanded Definition
Brokered OAuth is a delegated access pattern in which a third party sits between an application and the OAuth authorization flow, often handling consent capture, token exchange, token storage, or refresh logic. In NHI and IAM operations, the broker may be a SaaS integration layer, an orchestration service, or a platform component that reduces direct implementation effort while introducing a separate identity boundary that must be governed.
Definitions vary across vendors on whether brokered OAuth includes only token mediation or also broader delegated permission management. The practical distinction is that the application does not directly own the full OAuth lifecycle, so security teams must verify who can create, read, refresh, and revoke the brokered tokens. This is especially important when the broker is trusted by multiple downstream systems and can silently expand access scope over time. For a control-oriented view, the NIST Cybersecurity Framework 2.0 is useful for mapping governance, monitoring, and recovery responsibilities across that boundary.
The most common misapplication is treating the broker as a simple implementation detail, which occurs when teams fail to inventory the broker as a separate privileged NHI component.
Examples and Use Cases
Implementing brokered OAuth rigorously often introduces visibility and revocation complexity, requiring organisations to weigh faster integration against a harder-to-audit trust chain.
- A SaaS connector stores refresh tokens on behalf of a business application, allowing the app to access email or CRM data without handling user consent directly.
- An integration platform brokers OAuth for multiple tenant connections, making it easier to onboard customers while increasing the number of token holders that must be reviewed.
- A managed automation tool exchanges short-lived authorizations for long-lived access and then uses those tokens to act across cloud services and APIs.
- During an incident review, investigators trace suspicious API activity back to a broker rather than the application itself, which delays containment until the broker’s scopes are understood. That pattern is visible in cases such as the Salesloft OAuth token breach, where token-mediated access became the attack path.
- Security teams compare brokered access against the OAuth threat model in the OAuth 2.0 Authorization Framework to confirm which party is responsible for token lifecycle controls.
In practice, brokered OAuth is also common when a platform abstracts direct app-to-provider integration, but the broker still needs documented offboarding and revocation procedures.
Why It Matters in NHI Security
Brokered OAuth matters because it can hide durable credentials behind an integration layer that teams forget to inventory. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and another 47% reporting only partial visibility, which makes brokered access difficult to monitor and revoke. The risk is not the existence of delegation itself, but the accumulation of unreviewed trust relationships, over-broad scopes, and stale refresh tokens.
In NHI governance, brokered OAuth should be treated as a privileged identity path with named owners, scope limits, logging, and periodic access review. That aligns with the identity lifecycle and monitoring emphasis in the NIST Cybersecurity Framework 2.0 and with operational lessons from incidents such as the Dropbox Sign breach, where third-party access paths can become a control failure if they are not aggressively governed.
Organisations typically encounter the consequences only after a vendor compromise, unauthorized data pull, or token abuse event, at which point brokered OAuth becomes 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 CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Brokered OAuth creates a separate non-human identity boundary that must be inventoried and owned. |
| NIST CSF 2.0 | PR.AC-4 | Brokered access depends on least-privilege permissions and controlled authorization paths. |
| NIST CSF 2.0 | DE.CM-1 | Brokered tokens require continuous monitoring because the broker can mask downstream access activity. |
Inventory each brokered OAuth path, assign ownership, and review scopes and revocation readiness on a schedule.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
