A delegated token broker is an intermediary service that acquires, stores, refreshes, or invalidates access tokens on behalf of an application. It reduces integration overhead, but it also becomes part of the identity trust chain and must be governed like any other access control dependency.
Expanded Definition
Delegated token brokerage is the pattern where one service acts on behalf of another to obtain, cache, refresh, or revoke access tokens. It is common in integrations that need to simplify OAuth flows, centralise credential handling, or hide downstream identity complexity from application code. In NHI security, the broker is not just plumbing; it is a privileged identity component that can expand or constrain blast radius depending on how it is designed.
Definitions vary across vendors because some teams use the term for a lightweight token relay, while others mean a full policy-enforcing broker with vault, rotation, and revocation responsibilities. From an operating model perspective, the key distinction is whether the broker merely forwards tokens or whether it becomes an active control point for issuance, lifecycle management, and access decisions. That difference matters because token custody creates new trust boundaries, especially when brokers serve agents, CI/CD systems, or distributed microservices. The most common misapplication is treating a broker as a passive middleware layer when it actually stores reusable tokens in a production path.
For governance context, NIST’s NIST Cybersecurity Framework 2.0 frames this kind of dependency through access control, asset management, and resilience expectations, even though it does not name token brokerage directly.
Examples and Use Cases
Implementing delegated token brokerage rigorously often introduces an availability and trust-centralisation tradeoff, requiring organisations to weigh simpler app integration against a more sensitive identity choke point.
- A SaaS platform uses a broker to manage OAuth refresh tokens for customer tenants, so application pods never handle long-lived credentials directly.
- A data pipeline calls multiple APIs through a broker that exchanges short-lived access tokens per job, reducing token sprawl but increasing dependency on revocation logic.
- An AI agent platform routes tool access through a broker so each agent session receives scoped credentials instead of shared service tokens.
- A support workflow centralises token renewal for internal apps, which simplifies operations but can mask overbroad permissions if RBAC is weak.
Real-world incidents show why this pattern matters. In the Salesloft OAuth token breach, token handling became the path to downstream access rather than a background implementation detail. Similar risks appear in the JetBrains GitHub plugin token exposure, where integration convenience collided with credential exposure.
Why It Matters in NHI Security
Delegated token brokerage becomes a security problem when teams fail to treat the broker as an NHI control surface. If the broker can mint, refresh, or store tokens, then compromise of the broker can expose every application path that relies on it. That makes lifecycle discipline essential: token scope, rotation, expiry, revocation, and auditability all need explicit ownership. In mature NHI programs, this pattern should align with least privilege, just-in-time access, and zero standing privilege, not with permanent access delegation.
This is not a theoretical concern. According to The 2025 State of NHIs and Secrets in Cybersecurity from Entro Security, 91% of former employee tokens remain active after offboarding, a reminder that token lifecycle failures often persist long after the original use case ends. The same governance issue shows up in secret sprawl, where tokens are copied into tickets, repos, or collaboration tools instead of being centrally controlled. For broader operational guidance, the NIST Cybersecurity Framework 2.0 supports the same principle: identity dependencies must be discoverable, protected, and recoverable.
Organisations typically encounter the consequences only after an offboarding event, token leak, or downstream API abuse, at which point delegated token brokerage 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 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 token and secret handling as a core NHI control concern. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access protections apply to token brokers as access dependencies. |
| NIST Zero Trust (SP 800-207) | Zero trust expects every delegated access path to be continuously evaluated. |
Treat token brokerage as an access control asset and document who can issue, refresh, and revoke tokens.
