OAuth token mishandling in SaaS creates a hidden trust gap

At a glance

What this is: This research shows how SaaS providers mishandling OAuth tokens can expose GitHub and other connected accounts through plaintext token leakage and weak client-side handling.

Why it matters: It matters because identity teams have to govern third-party OAuth integrations as part of NHI risk, not treat them as a vendor-side implementation detail.

👉 Read Truffle Security's analysis of mishandled OAuth tokens in SaaS integrations

Context

OAuth access tokens are bearer credentials, which means anyone who obtains them can act with the granted scope until the token is revoked or expires. In this article, the weak point is not the identity provider, but the SaaS platform that stores, exposes, or forwards the token in ways the browser can reach.

That distinction matters for NHI governance because OAuth-connected SaaS tools sit inside the delegated identity chain and can become a pivot layer into corporate systems. When those tools mishandle tokens, the risk is not theoretical account abuse but an access pathway that survives normal user expectations about “Sign in with” flows.

Key questions

Q: What breaks when OAuth tokens are compromised in connected SaaS environments?

A: When OAuth tokens are compromised, attackers can inherit delegated access without defeating passwords or MFA. In connected SaaS environments, that access can spread into multiple applications, cached data sets, and embedded records. The failure is not only token theft, but the assumption that one app boundary contains the blast radius. That assumption rarely holds once integrations are chained.

Q: Why does mishandled OAuth token storage create such high compromise risk?

A: Mishandled tokens create risk because OAuth shifts trust to the SaaS provider handling the token, not just the identity provider. If an attacker can read or steal that token, they can act as the user against connected services without needing a password. That makes one exposed token a direct path into GitHub, Azure, Slack, or other linked accounts.

Q: How can security teams tell whether a SaaS integration is leaking tokens?

A: Look for tokens returned in responses, readable in browser tools, or accessible through scripts that should never need them. Any endpoint that serves a bearer token to the client is a strong indicator of a broken OAuth implementation. The practical test is whether the token can be observed or replayed without involving a trusted server path.

Q: Should organisations review OAuth scopes before approving SaaS connections?

A: Yes, because the scope defines the blast radius if the token is stolen or mishandled. A narrow token may only expose profile or email data, while a broader token can open repositories or administrative workflows. Scope review should therefore be treated as a core approval step, not a post-incident cleanup task.

Technical breakdown

How plaintext OAuth token exposure breaks the client-server boundary

In a normal OAuth flow, the SaaS application exchanges an authorization code for an access token and keeps that token on the server side. When the token is returned to the browser in plaintext, the application collapses that boundary and makes the credential reachable by client-side code, browser storage, or injected scripts. That turns an access token into a browser-exposed secret rather than a back-end bearer credential. The article shows that this is especially dangerous in web apps, where the token should never be visible to the user. Practical implication: keep OAuth access tokens off the client path and treat any browser-readable token as a governance failure.

Practical implication: keep OAuth access tokens off the client path and treat any browser-readable token as a governance failure.

Why XSS turns token mishandling into account pivoting

If an application already exposes a token to the browser, cross-site scripting becomes a direct exfiltration path. Malicious JavaScript can read the token from the endpoint or browser context and send it to an attacker-controlled server, after which the token can be used to call downstream APIs as the victim. This is not a new attack primitive, but token exposure gives XSS a much higher-value target than session data alone. Practical implication: browsers must never become the trust boundary for delegated identity credentials, because any script execution flaw can convert into account compromise.

Practical implication: browsers must never become the trust boundary for delegated identity credentials, because any script execution flaw can convert into account compromise.

OAuth scope and token sensitivity are not interchangeable

The article’s practical point is that not every token compromise has the same blast radius. A token limited to email access is materially different from one that can reach repositories, administrative data, or automation workflows. OAuth scopes define what the token can do, while token handling defines who can steal it; both govern risk, but in different ways. That makes scope review a governance control, not just a developer setting. Practical implication: evaluate the specific scopes granted to each SaaS integration and separate low-value access from tokens that can reach high-value systems.

Practical implication: evaluate the specific scopes granted to each SaaS integration and separate low-value access from tokens that can reach high-value systems.

Threat narrative

Attacker objective: The attacker wants delegated OAuth access that lets them pivot from a compromised SaaS integration into the target user’s connected corporate accounts.

1. Initial access begins when a SaaS provider exposes a GitHub access token in a browser-reachable endpoint or through another client-side handling flaw.
2. Credential access occurs when an attacker uses XSS, session hijacking, or similar browser compromise to retrieve the token.
3. Lateral movement follows when the stolen token is replayed against GitHub or another connected service with the victim’s delegated privileges.
4. Impact occurs when the attacker pivots into repositories, user accounts, or downstream SaaS environments using the harvested token.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Storm-1283 OAuth apps abuse 2023: Storm-1283 added secrets to new and existing OAuth apps in Entra ID and used them to run Azure cryptomining VMs, costing victims up to $1.5 million.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth token exposure is a delegated identity failure, not just an application bug: When a SaaS platform returns access tokens to the browser, it moves a bearer credential into a zone where the user and the attacker can both reach it. That breaks the core assumption that the token stays inside trusted back-end handling. The implication is that OAuth governance must include client-side exposure paths, not only authorization setup.

Trusted SaaS sits inside the identity perimeter now: The article shows that third-party integrations can become the softest place in the access chain even when the identity provider is sound. A platform that mishandles tokens can turn a routine connection into a corporate account pivot. Practitioners should treat delegated SaaS access as part of the identity estate, with explicit control over scopes, storage, and retrieval paths.

Blast radius is determined by token scope plus token leakage path: A leaked token with narrow scope is a nuisance; a leaked token with repository or administrative scope becomes a material compromise path. The security model has to account for both the privilege granted and the place where the token can be stolen. That is why OAuth review belongs in NHI governance and application security at the same time.

Browser-readable credentials create a false sense of normality: Users expect OAuth consent flows to be safe because the interface feels familiar. But familiarity does not equal safe credential handling, especially when the provider on the other side may store or expose tokens badly. The governance lesson is that identity assurance cannot stop at the sign-in button; it must extend to every system that can replay the token.

OAuth misuse in SaaS should be treated as a lifecycle problem: Tokens outlive the moment they are issued, and the risk continues until they are rotated, revoked, or rendered unusable by scope reduction. That puts credential lifecycle and offboarding on the same plane as initial grant decisions. Practitioners need to govern the full delegated-access lifecycle, not just the onboarding event.

From our research library:

• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.

What this signals

Delegated access now needs the same scrutiny as local credentials: SaaS applications that can replay OAuth tokens into core business systems are part of the identity estate, even when the token originates elsewhere. That means access review, scope control, and offboarding have to extend beyond the IdP into the SaaS layer where the token is actually handled.

OAuth hygiene is increasingly an NHI governance issue: Browser-safe handling, token storage, and replay boundaries define whether a third-party integration behaves like a controlled delegate or an uncontrolled credential sink. For programmes that already manage secrets and service accounts, OAuth-connected SaaS should be assessed with the same lifecycle rigor.

For practitioners

• Audit browser-exposed token paths Inspect SaaS integrations for endpoints or scripts that return access tokens to the browser, especially where server-side handling should be the only trust boundary.
• Tighten OAuth scope grants Review each connected app’s scopes and reduce delegated access to the minimum set required for the use case, with special attention to repository and admin permissions.
• Treat SaaS connections as identity assets Inventory third-party SaaS tools that can replay OAuth tokens into corporate services and include them in access reviews, offboarding, and renewal decisions.
• Test for token leakage in runtime traffic Manually inspect application traffic and browser behavior to confirm that tokens are not visible in responses, scripts, or storage reachable by client-side code.

Key takeaways

• OAuth token mishandling in SaaS creates a delegated access risk because browser-exposed bearer credentials can be replayed outside the intended server-side trust boundary.
• The article reports that more than 10% of 75 popular SaaS vendors mishandled GitHub access tokens, showing that the problem is operational rather than theoretical.
• The key control is to keep tokens out of client reach, narrow scopes aggressively, and govern third-party SaaS connections as part of identity lifecycle management.

Key terms

• OAuth Access Token: A short-lived bearer credential issued after successful authorization that allows an application to call APIs on a user's behalf. In NHI governance terms, it is a reusable access artifact whose scope, expiry, and revocation path must be controlled like any other privileged credential.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Token Replay: Token replay is the reuse of a valid access or refresh token by someone other than the intended client. The token may still be unexpired and cryptographically correct, so the compromise often shows up only through context anomalies such as location, device, or session overlap.
• Browser-exposed secret: A credential, token, or other sensitive value that can be accessed through client-delivered code or related front-end workflows. These exposures are especially risky because they can be copied at scale, reused outside intended context, and remain valid until explicitly revoked.

What's in the full report

Truffle Security's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how token exposure happens in typical OAuth flows
• The specific browser-side behaviours that make plaintext token handling dangerous
• The remediation approach Truffle Security used when disclosing findings to affected organisations
• The practical differences between low-scope and high-scope token exposure

👉 The full Truffle Security post covers the OAuth flow examples, real-world token exposure patterns, and disclosure outcomes.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.