Should organisations allow browser-based storage of access tokens for SaaS integrations?

Why This Matters for Security Teams

Browser-based token storage turns a SaaS integration into a high-friction trust decision. It can be acceptable for low-risk, user-owned workflows, but for organisational integrations it expands the exposure surface to the browser profile, extensions, cached state, and accidental reuse across tabs or sessions. That matters because tokens are not just login artifacts; they are often the standing authority that lets an integration read mail, modify records, or move data between systems.

The operational risk is easier to see in breach reporting than in policy documents. NHIMG has documented how OAuth tokens have been abused in incidents such as the Salesloft OAuth token breach and how exposed tokens continue to enable access long after the original event. Industry guidance also points to identity-specific controls rather than generic app security; the OWASP Non-Human Identity Top 10 treats secret handling, lifecycle control, and overprivilege as first-order risks, not edge cases.

For practitioners, the issue is not whether a browser can technically hold a token. It is whether the organisation can prove the token is isolated, short-lived, narrowly scoped, and promptly revoked when the work ends. In practice, many security teams only discover the weakness after a collaboration tool, browser plugin, or shared machine has already turned a convenience choice into an incident.

How It Works in Practice

For SaaS integrations, the safer pattern is to treat browser storage as a last resort and to prefer server-side token custody, workload identity, or delegated access flows that keep secrets out of the end-user browser. Where browser use is unavoidable, the control objective is to reduce the token’s usefulness if it is exposed. That means short TTLs, tight scope, explicit revocation, and session binding where the provider supports it. It also means separating human sign-in from non-human automation, so the token is governed as an NHI secret rather than a convenience credential.

A practical control set usually includes:

• Issue the narrowest possible scopes and avoid refresh tokens in the browser unless there is a clear business need.
• Use just-in-time access where the integration only receives authority for the task at hand, then loses it automatically.
• Prefer secure storage managed by the application backend or vault, not local browser persistence.
• Monitor for token replay, unusual geography, and access from untrusted devices or extensions.
• Revoke on task completion, user offboarding, or permission drift, not on a fixed annual cycle.

That guidance aligns with NHIMG research showing that 44% of NHI tokens are exposed in the wild across tools like Teams, Jira, Confluence, and code commits in The 2025 State of NHIs and Secrets in Cybersecurity. It also fits the broader secrets-sprawl problem described in Guide to the Secret Sprawl Challenge, where duplication and uncontrolled placement make revocation and audit harder. Current guidance suggests pairing this with policy-as-code and identity-aware enforcement, as discussed in the OWASP Non-Human Identity Top 10, rather than relying on user discipline alone. These controls tend to break down when the SaaS vendor only supports long-lived bearer tokens and the integration must run in an unmanaged, multi-user browser environment.

Common Variations and Edge Cases

Tighter token controls often increase implementation overhead, so organisations need to balance user convenience against the cost of building a safer integration path. That tradeoff is real in small teams, partner portals, and legacy SaaS platforms where backend service accounts or workload identity are not available.

There is no universal standard for this yet, but current guidance suggests three common exceptions. First, short-lived browser tokens can be acceptable for low-impact personal workflows where the data is already exposed to the signed-in user and the integration is disposable. Second, browser storage may be tolerated temporarily during migration, provided the token is time-boxed and wrapped with compensating controls such as device posture checks, strong CSP, and rapid revocation. Third, some vendors still force browser-mediated OAuth flows, but that does not justify storing the resulting token indefinitely.

Security teams should be especially cautious when the browser is on a shared workstation, when extensions are not tightly managed, or when the integration can laterally access multiple SaaS tenants. NHIMG has shown how token compromise can cascade across collaboration tools in incidents like the Internet Archive breach and Sisense breach, where the issue was not just credential theft but the breadth of what those credentials unlocked. In those environments, browser storage stops being a convenience feature and becomes an unnecessary standing privilege.

Related resources from NHI Mgmt Group

• What are the implications of using OAuth tokens in third-party integrations?
• What breaks when organisations do not map the access path of AI and SaaS integrations?
• Why do ephemeral credentials still leave risk in machine access models?
• What makes OAuth tokens risky in NHI environments?