Use short-lived access tokens for API calls, keep the authorization code flow for server-side apps, and avoid sending ID tokens or refresh tokens to places that do not need them. Minimise claims in the token payload, store only what is necessary, and rely on server-side session handling where possible. That reduces exposure while preserving user experience and control over delegated access.
Keep browser exposure limited to what the client actually needs
The browser should receive the minimum material required to keep the user signed in and to call the API, nothing more. That means keeping bearer tokens short-lived, avoiding long-lived refresh tokens in browser storage, and not placing identity tokens where they can be read by scripts, extensions, or injected content. For SaaS teams, the practical question is not whether the browser can hold a token, but whether it must.
A safer pattern is to treat the browser as an untrusted delivery surface and let the server handle anything that needs durable trust, stronger confidentiality, or broader privilege. Where session state is enough, prefer a server-side session over exposing reusable secrets to the client. Where API access is unavoidable, scope the token narrowly, minimise claims, and keep the lifetime short enough that leakage has limited value.
That design aligns with known token-abuse paths such as stolen OAuth material and exposed API keys, which often turn a single browser-side leak into broader SaaS access. Cases like Salesloft OAuth token breach and Internet Archive breach are reminders that token placement and token lifetime are control decisions, not implementation details. The broader token and secret-exposure pattern is also covered in Ultimate Guide to NHIs.
Choose flows that preserve trust boundaries
Token-based authentication is not one design, it is a set of trade-offs between convenience, delegation, and containment. For browser-based SaaS, the authorisation code flow with PKCE is generally the safer default because it keeps the strongest secrets off the front end while still supporting interactive sign-in. By contrast, patterns that place reusable credentials in the browser create a much larger exposure window and make revocation, rotation, and incident response harder.
Good practice is to separate interactive login from backend trust. The browser should prove the user is present, but the server should decide what durable credentials it stores, how those credentials are refreshed, and what downstream APIs they may reach. That separation matters most when the SaaS product integrates with third-party services, because a front-end leak can become a cross-system access event rather than a local application issue. Relevant breach patterns include Dropbox Sign breach and Klue OAuth Supply Chain Breach.
When you do need delegated access, design for containment from the start. Use audience restriction, tight scopes, and explicit token separation so that a browser token for UI access cannot quietly double as a general-purpose credential for other services. If the token can unlock multiple systems, the browser has effectively become a high-risk trust boundary.
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, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Browser-exposed tokens are secrets that can be stolen and reused. |
| NHI-02 — Overprivileged Non-Human Identities | Scoping and minimising claims directly reduces token blast radius. | |
| NHI-03 — Credential Lifecycle and Rotation | Short-lived tokens and revocation reduce exposure after leakage. | |
| Recommendation — Keep reusable tokens out of the browser and store them only in controlled server-side locations. Issue the narrowest token scope and claims needed for each browser-facing workflow. Use short lifetimes and enforce rapid revocation for any token that reaches the client. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Credential Management | Token handling is an identity and access control concern for SaaS applications. |
| PR.AC-4 — Access Permissions and Authorizations | Least privilege and audience restriction limit what a leaked token can do. | |
| PR.DS-1 — Data-at-Rest Protection | Avoiding browser storage for sensitive tokens reduces client-side data exposure. | |
| Recommendation — Manage browser-facing tokens as controlled credentials with explicit issuance and revocation rules. Constrain each token to the minimum permissions and audience required. Keep sensitive authentication material out of browser storage wherever feasible. | ||
| CIS Controls v8 | 6.3 — Access Control Management | Token-based auth needs enforced least privilege and controlled access paths. |
| 6.8 — Unmanaged Assets and Access Paths | Client-side token placement creates uncontrolled exposure and reuse paths. | |
| 8.2 — Audit Log Management | Browser-side token use should be observable for abuse and incident response. | |
| Recommendation — Apply least privilege to every token that can be used from the browser. Eliminate unnecessary client-held credentials and revoke any exposed browser-side token quickly. Log token issuance, use, and revocation events so browser exposure can be investigated. | ||
| NIST SP 800-63 | SP 800-63B — Authentication and Lifecycle Management | Token handling must support secure authentication and session lifecycle decisions. |
| Recommendation — Use authentication flows that keep long-lived authenticators away from the browser. | ||
Practitioner Guidance
What to verify: Confirm that no refresh token, ID token, or long-lived API credential is available to client-side code, browser storage, logs, or error telemetry. If the browser must hold an access token, verify the shortest feasible lifetime, the narrowest feasible scope, and a clear revocation path.
Decision rule: If the browser needs to call only your own API, prefer a session-backed design that keeps durable trust on the server. If the browser must call a downstream API directly, treat the token as exposed by design and compensate with narrow scope, short lifetime, and reduced claims.
What practitioners underestimate: The main failure is often not a dramatic compromise of the auth flow, but token reuse after a seemingly minor leak through JavaScript, debugging tools, browser extensions, or third-party scripts. A token that is valid only briefly and for only one audience is much easier to contain than a reusable front-end secret.
Practitioner takeaway: The safest SaaS pattern is to make the browser useful, not trusted, and to keep any credential that can outlive the current request on the server side whenever possible.
Related resources from NHI Mgmt Group
- How should teams implement hybrid deployment for LLM development workflows without exposing sensitive data to the SaaS control plane?
- How should security teams implement credential access for browser-based AI agents without exposing secrets to the model?
- How should security teams implement short-lived access to sensitive databases without exposing customer data broadly?
- How should security teams decode SAML messages without exposing sensitive authentication data?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
