Notifications
Clear all
Topic starter
08/06/2026 4:20 pm
TL;DR: Legacy SAML browser models are giving way to API-centric web architectures, but Curity argues that many modernisation projects still mishandle browser tokens, session handling, and backend complexity. The practical shift is clear: secure web design now depends on separating concerns, keeping tokens out of the browser, and treating APIs as the centre of data protection.
NHIMG editorial — based on content published by Curity: modern web security design for SAML-to-OAuth migration
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Use short-lived HTTP-only cookies for API message transport Treat browser cookies as constrained API credentials, not long-lived session stores.
- 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.
What's in the full article
Curity's full article covers the operational design detail this post intentionally leaves for the source:
- The SAML-to-OAuth migration sequence, including how to repoint legacy apps before changing their authentication model.
- The browser security trade-offs behind access tokens, refresh tokens, and HTTP-only cookie handling.
- The backend for frontend and token handler implementation pattern for API-side session control.
- The rendering-style comparisons across pre-rendering, client-side rendering, and server-side rendering.
👉 Read Curity's analysis of API-first web modernization and browser security →
API-first web modernization: are your identity controls keeping up?
Explore further
08/06/2026 5:55 pm
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.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Modern web architecture needs stronger identity controls for APIs
