A token broker is a service that issues, refreshes, or mediates access tokens on behalf of an application. It simplifies implementation, but it also becomes part of the trust chain, so organisations must define ownership, logging, renewal policy, and revocation responsibilities.
Expanded Definition
A token broker sits between an application and the systems that trust its identity, issuing, refreshing, or exchanging access tokens so the application does not handle every credential flow itself. In NHI security, that convenience changes the trust boundary: the broker becomes a sensitive control point for authentication, session continuity, and token lifecycle decisions. That is why standards-oriented guidance such as the NIST Cybersecurity Framework 2.0 matters here, even when it does not name token brokers explicitly. Definitions vary across vendors, especially in API gateways, identity platforms, and agent runtimes, so the broker may be implemented as a service, library, sidecar, or delegated identity exchange layer. In practice, the important distinction is whether it mints or mediates tokens that other software can use independently of a human operator.
For NHI governance, the broker should be treated as part of the identity plane, not just middleware. It needs clear ownership, scoped privileges, durable audit logs, and explicit revocation paths. The most common misapplication is treating the broker as a neutral utility, which occurs when teams centralise token handling without assigning lifecycle accountability or breach response ownership.
Examples and Use Cases
Implementing a token broker rigorously often introduces operational coupling, requiring organisations to weigh simpler application development against tighter dependency management, stricter logging, and more complex incident response.
- An internal platform uses a broker to exchange short-lived service credentials for downstream API access, reducing hardcoded secrets in application code.
- A workload in a zero trust environment requests tokens through a broker that enforces policy before allowing access to protected data services, aligning with NIST Cybersecurity Framework 2.0 control expectations.
- A SaaS integration uses a broker to refresh OAuth access tokens on behalf of multiple applications, which simplifies deployment but increases blast radius if the broker is compromised.
- During credential rotation, the broker becomes the only approved path for new tokens while old tokens are revoked, a pattern frequently discussed in the Guide to the Secret Sprawl Challenge.
- After an incident, investigators trace which applications received which tokens through a broker, using its logs to reconstruct exposure paths similar to the Salesloft OAuth token breach.
In well-governed environments, token brokers are also used to standardise token renewal windows, enforce audience restrictions, and reduce direct exposure of long-lived secrets in CI/CD and agent workflows.
Why It Matters in NHI Security
Token brokers matter because they concentrate trust, and concentrated trust is where failures become systemic. When the broker is over-privileged, weakly logged, or poorly scoped, one compromise can affect every application that depends on it. That risk is amplified by real-world exposure patterns: in The 2025 State of NHIs and Secrets in Cybersecurity, Entro Security reported that 44% of NHI tokens are exposed in the wild, showing how often token handling breaks down outside intended controls. This is why token broker governance must include revocation automation, least privilege, and clear separation between token issuance and application runtime access. Token brokers also intersect with broader secrets sprawl issues described in the Guide to the Secret Sprawl Challenge, because broker logs, configs, and caches can themselves become exposure points if mishandled.
Organisations typically encounter the operational importance of a token broker only after tokens are found in tickets, code commits, or incident logs, at which point the broker 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-01 | Token brokers centralise issuance and lifecycle control for non-human identities. |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and access enforcement apply to token-mediated machine access. |
| NIST Zero Trust (SP 800-207) | AC-4 | Zero trust relies on continuous verification before token-backed access is granted. |
Treat broker issuance, refresh, and revocation as governed NHI controls with named ownership.
