Modern web architecture needs stronger identity controls for APIs

At a glance

What this is: This is an analysis of why SAML-era browser security models no longer fit API-first web applications, and how token handler patterns and BFF design change the security boundary.

Why it matters: It matters because IAM, NHI, and application security teams now have to govern browser access, API credentials, and backend session handling as one architecture instead of separate problems.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Curity's analysis of API-first web modernization and browser security

Context

Modern web architecture now revolves around APIs, not browser sessions alone. That shift changes how identity and data security should be designed, because browser-side authentication patterns from the SAML era were built for a different application model. In an API-first environment, the browser should not become the place where long-lived trust is stored.

The article argues that many web modernisation projects fail when they treat authentication as the main problem instead of the full identity and API boundary. For IAM teams, the real question is how access tokens, cookies, backend session state, and API authorisation work together without pushing sensitive logic back into the frontend.

Key questions

Q: How should security teams modernise SAML-based web apps for API-first architectures?

A: Security teams should modernise by redesigning the web and API boundary together. That means using OAuth for API access, keeping sensitive session state on the backend side, and moving browser-facing flows toward short-lived credentials and hardened cookies. The goal is to reduce trust placed in the browser while preserving a clean migration path from legacy SAML patterns.

Q: Why do browser-based applications need different identity controls than legacy SAML websites?

A: Browser-based applications now interact with APIs directly, so the browser is no longer just a presentation layer. That changes the risk model because tokens, cookies, and refresh flows can be exposed to XSS, origin abuse, and replay. Legacy SAML websites often assumed a more bounded browser session, which does not fit API-centric design.

Q: What breaks when access tokens are handled too broadly in the browser?

A: When access tokens are exposed too broadly in the browser, the application inherits the browser's weakest trust properties. Frontend code can become a target for token theft, session confusion, and cross-origin misuse. Teams then have to compensate with much stricter browser controls, shorter credential lifetimes, and stronger backend enforcement.

Q: Should organisations use a backend for frontend in web modernisation projects?

A: Organisations should use a backend for frontend when they want modern UI delivery without pushing security-critical session handling into the browser. A BFF can centralise OAuth code flow handling, token exchange, and cookie issuance, which simplifies the frontend and makes the security model easier to govern.

Technical breakdown

SAML browser profiles versus OAuth browser-based applications

SAML browser profiles were designed for a world where the identity provider authenticated the user and the website consumed assertions in the browser flow. OAuth 2.0 browser-based applications shift that model by issuing access tokens for API calls and refresh tokens for renewal. The security difference is not cosmetic. With OAuth, the frontend becomes a client to APIs, not the system that should hold durable session trust. That architecture is more compatible with modern web applications, but only if token handling is designed carefully and sensitive state is not left in the browser.

Practical implication: teams modernising from SAML should redesign authentication and API authorisation together, not as separate migration tracks.

Why browser token handling changes the security boundary

Browser-based applications are exposed to cross-site scripting, cookie interception, origin confusion, and token replay if the credential model is weak. The article stresses that access tokens should not live in the browser when they can be avoided, and that short-lived HTTP-only cookies can act as API message credentials instead. That matters because the browser is an execution environment with less trust than a backend. Once sensitive credentials are exposed to frontend code, browser hardening, origin controls, and token lifetime become first-order security controls rather than implementation details.

Practical implication: move credential transport into hardened cookie patterns and reduce the amount of secret-bearing state exposed to frontend code.

Token handler patterns and backend for frontend architectures

The token handler pattern places the security-sensitive work on the API side of the architecture. A backend for frontend handles OAuth code flow, cookie issuance, backend token exchange, and web-specific protections, while the frontend remains lightweight and focused on UI. That separation reduces the pressure on web developers to run backend session stores, redirect logic, and expiry handling. It also aligns better with CDN-based hosting and API-centric deployment models. In effect, the architecture centralises trust where it can be governed, logged, and constrained more consistently.

Practical implication: adopt BFF or token handler patterns when you need browser modernisation without reintroducing legacy session complexity into the web tier.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Modern web modernization has become an identity boundary problem, not just a frontend refresh. The article shows that moving from SAML to OAuth changes where trust lives, how credentials move, and which layer owns session state. That makes browser security, API authorisation, and backend identity handling one governance problem rather than three separate projects. Practitioners should treat modernization as an identity architecture redesign.

Browser-held tokens create a governance blind spot that legacy SAML models never had to solve. SAML assertions were consumed in a more bounded browser flow, while OAuth-based web apps can expose access and refresh token handling to frontend risks such as XSS and origin misuse. The architectural issue is not OAuth itself but the choice to let the browser become the durable trust surface. Practitioners should assume the browser is the least reliable place to retain lasting authorization state.

Separated concerns is the right named concept for API-era web security. Web apps should not carry backend session complexity when APIs can own sensitive state, logging, and message credentials. The token handler pattern and BFF design reduce coupling between UI delivery and identity enforcement, which is exactly where older hybrids become fragile. This is the architecture most likely to survive continued web and API convergence.

Zero-trust web design now depends on treating cookies as API credentials, not web conveniences. When cookies transport access tokens to backend APIs, they become part of the API security model and must be governed accordingly. That shifts design attention toward origin restrictions, short-lived credentials, and server-side enforcement rather than frontend assumptions. Practitioners should align web architecture with API security controls from the start.

Lifecycle thinking still applies here, even though the subject is web architecture. Modernisation projects often fail because teams migrate the authentication protocol but do not retire the older hosting, session, and integration dependencies that came with it. That leaves a mixed estate in which SAML-era patterns persist alongside OAuth-era controls, increasing complexity. Practitioners should plan the migration as a full lifecycle transition, not a protocol swap.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• If your modernization plan also touches service accounts, rotation, or offboarding, Ultimate Guide to NHIs is the natural next reference point.

What this signals

Separated concerns: the article’s central design lesson is that browser security and API security can no longer be treated as different programmes. Teams that modernise authentication without relocating session state and credential handling will keep recreating legacy risk in a newer stack. The practical signal is to align web architecture decisions with IAM governance from the outset.

As organisations move toward API-centric delivery, the boundary between human access, application tokens, and backend trust becomes harder to see and easier to mismanage. That is why identity teams should expect more scrutiny of browser token handling, cookie scope, and the way web apps delegate enforcement to backend services. For teams using modern browser security patterns, the NIST Cybersecurity Framework 2.0 remains a useful governance anchor for mapping identity controls to protect, detect, and respond functions.

For practitioners

• Separate authentication from web rendering Keep sensitive session state and API authorization logic on the API side, and let the browser focus on presentation and request initiation. This reduces the chance that frontend code becomes the control point for durable trust.
• Use short-lived HTTP-only cookies for API message transport Treat browser cookies as constrained API credentials, not long-lived session stores. Pair them with strict SameSite and CORS controls so browser-origin behaviour stays bounded.
• Adopt a backend for frontend for modern apps Place OAuth code flow handling, token exchange, and cookie issuance in a backend for frontend so the frontend does not need to manage secret-bearing infrastructure. That keeps the UI layer lighter and the security boundary clearer.
• Plan SAML-to-OAuth migration as a phased architecture change Repoint legacy SAML applications to the new identity system first, then upgrade them individually to OAuth once the new request path is stable. This avoids downtime and gives teams time to remove session-store dependencies.

Key takeaways

• API-first web design changes identity governance by moving trust away from the browser and into backend-controlled flows.
• Legacy SAML patterns can survive migration projects unless teams redesign token handling, session state, and API enforcement together.
• Modernisation should be treated as an IAM and security architecture transition, not as a simple frontend technology upgrade.

Key terms

• Backend for Frontend: A backend for frontend is an API-side component that serves a specific browser or mobile frontend and handles security-sensitive work on its behalf. In modern identity design, it can manage OAuth flow, token exchange, and cookie issuance so the UI layer stays lighter and less exposed.
• Token Handler Pattern: The token handler pattern moves browser credential handling into a controlled backend layer rather than leaving tokens in frontend code. It is especially useful when web applications need short-lived API credentials, strong cookie governance, and a clear separation between presentation and authorization responsibilities.
• API Message Credential: An API message credential is the browser-side credential used to transport authorised requests to backend APIs. In this article's context, it is not a general login session but a constrained transport mechanism that should be short-lived, tightly scoped, and protected from browser exposure.
• Separated Concerns: Separated concerns is the design principle of keeping presentation, session management, and API security responsibilities in different layers. For identity governance, it reduces coupling, makes trust boundaries clearer, and prevents web frontends from becoming the place where sensitive state is stored and enforced.

Deepen your knowledge

OAuth browser security and token handling are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are modernising web applications and need a governance lens that spans browser, API, and identity layers, it is worth exploring.

This post draws on content published by Curity: modern web security design for SAML-to-OAuth migration. Read the original.