Join our Newsletter — 33% off our NHI Course

Vendor-Held Tokens

OAuth refresh tokens or similar credentials stored and reused by a third-party service so it can act later without asking the user again. The security problem is not the token format itself, but the fact that compromise of the vendor environment can expose valid access to the customer estate.

What Vendor-Held Tokens Are and Why They Matter

Vendor-held tokens are not interesting because of a special token format, but because a third party keeps reusable access material on behalf of the customer. That design extends trust into the vendor environment, so the customer’s exposure depends on how well the vendor protects, scopes, and lifecycle-manages that stored credential.

This model is common in delegated integrations, offline access, and SaaS workflows that need to act later without prompting the user again. It can reduce friction, but it also means the token becomes a standing path into customer data if the vendor side is compromised, misused, or poorly isolated.

How Vendor-Held Tokens Work in Practice

At a practical level, the vendor receives or stores an OAuth refresh token or a similar long-lived secret, then uses it later to mint new access without involving the user. The customer no longer controls each session directly, so the security boundary shifts from the user’s device to the vendor’s systems and processes.

That shift is why vendor-held tokens are best understood as a delegated trust mechanism. The token is often only one part of the picture; the real issue is who can retrieve it, whether it is encrypted, how it is bound to a client or audience, and whether it can be reused outside the intended service path.

When this pattern is implemented well, it supports automation and continuity. When it is implemented loosely, it can blur the line between legitimate delegation and persistent access, especially if the vendor treats the token like an ordinary application secret instead of a high-value access grant.

Security Implications of Vendor-Controlled Access

Security risk rises because the vendor environment becomes part of the trust chain for the customer estate. If an attacker compromises the vendor, steals a token store, or abuses internal privileges, they may inherit valid access that looks legitimate to downstream systems. RFC 9700: Best Current Practice for OAuth 2.0 Security is relevant here because it addresses token theft and sender-constraining as core defences.

The same pattern also changes incident response. A customer may need to assume that a vendor-side compromise can outlast the original intrusion if tokens are not rotated, revoked, or audience-restricted quickly. RFC 8707: Resource Indicators for OAuth 2.0 and RFC 9449: OAuth 2.0 Demonstrating Proof of Possession both matter because narrow audience binding and proof-of-possession reduce replay value.

Vendor-held tokens can also create visibility gaps. The customer may see successful API calls or data access, but not the internal handling of the credential that enabled them. That is why breach reviews often focus on whether the token was static, whether it had broad scope, and whether the vendor kept it longer than operationally necessary.

Design Patterns That Reduce Exposure

The safest implementations treat vendor-held tokens as temporary, tightly scoped, and revocable. Shorter lifetimes reduce the payoff of compromise, while audience restrictions and sender constraints reduce the chance that a stolen token can be replayed elsewhere. RFC 8693: OAuth 2.0 Token Exchange is useful when a vendor needs delegated access without reusing a broad upstream grant directly.

Token storage deserves the same discipline as any other secret-bearing system. Encryption at rest, controlled access, rotation, revocation, and strong separation between customer tenants all matter because the vendor is holding something that can act with the customer’s authority. RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens is a useful reference when binding a token to a client certificate is feasible.

Operationally, the most important question is whether the vendor truly needs to store the token at all. If the use case can be solved with narrower delegation, per-use issuance, or a different trust boundary, the design should move away from a reusable credential that can silently extend access.

Common Failure Modes and What They Reveal

Vendor-held tokens fail most often when a convenience choice becomes a standing privilege. Long-lived secrets, broad scopes, poor offboarding, and weak environment separation turn a delegated mechanism into a durable breach path. For a concrete explanation of why static credentials and long-lived secrets are dangerous, Ultimate Guide to NHIs, static vs dynamic secrets is a useful companion reference.

Another common failure is treating the vendor as a passive processor rather than an active trust boundary. Once the token lives in the vendor’s systems, the customer inherits the vendor’s logging quality, access controls, incident response maturity, and revocation discipline. If any of those are weak, the token becomes a high-leverage path to the customer estate.

Real-world incidents tend to follow the same pattern: a valid token is stolen, reused, or left in place long after the original event should have triggered revocation. That is why the core security question is not whether the token is an OAuth refresh token or some other credential, but whether the vendor can hold it without turning delegation into persistent exposure.