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.
Editorial analysis by NHI Mgmt Group, based on content published by Curity: “Modernize SAML Web Architectures the Right Way”.
Key questions
Q: How should security teams modernize identity controls for API-first web applications?
A: Security teams should redesign the application around separate web and API responsibilities.
Q: Why do browser-held tokens create more risk in modern web architectures?
A: Browser-held tokens increase risk because they are more exposed to XSS, origin abuse, and misconfiguration than API-side message handling.
Q: What breaks when teams keep using SAML-era web patterns for API-centric apps?
A: SAML-era patterns break when they assume the browser and website can carry the full security state.
Practitioner guidance
- Separate browser and API responsibilities Design the browser as a presentation layer and keep session state, token handling, and authorization enforcement on the API side of the architecture.
- Keep OAuth tokens out of the browser Use hardened cookie transport patterns and avoid exposing access or refresh tokens to frontend code or persistent browser storage.
- Adopt backend-for-frontend controls Place OAuth code flow handling, cookie issuance, and API request mediation in a dedicated backend-for-frontend layer instead of distributing those duties across the UI stack.
Bottom line: Modern web modernization is not just a framework upgrade. It is a redesign of where identity state, authorization, and data protection should live.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
08/06/2026 5:55 pm
API-first web modernization turns the browser into an edge channel, not the trust centre. The old assumption that a browser session can safely carry the core security state no longer holds when APIs govern sensitive data. That assumption breaks because authorization now depends on backend enforcement, not on frontend-held attributes or long-lived browser state. Practitioners should treat the browser as a presentation layer with tightly constrained credential handling.
A question worth separating out:
Q: What is the difference between browser session control and API-side session control?
A: Browser session control keeps too much trust in the frontend, where it is exposed to client-side execution and cookie handling issues. API-side session control places credential transport, session state, and request enforcement closer to the resource owner. For modern web applications, that distinction is critical because APIs are now the real protection point for sensitive data.
👉 Read our full editorial: Modern web architecture needs stronger identity controls for APIs
This post was modified 1 day ago by NHI Mgmt Group