Modernize SAML Web Architectures the Right Way

Many existing websites use legacy web architectures and outdated security solutions. One example is the Web Browser Profile from the Security Assertion Markup Language (SAML) 2.0 security standard, which was released back in 2005. In this model, websites externalize user authentication to SAML Identity Providers. After logins, websites receive user attributes in SAML assertions and use them to authorize requests from the browser frontend.

However, web architecture has moved on. Modern applications increasingly rely on APIs to manage data security. The move to APIs significantly changes how organizations should implement both data security and web architectures. Many companies are now working on SAML to OAuth migration and web modernization projects, replacing legacy SAML web architecture with more scalable and secure models. But what does an optimal solution look like?

Web modernization is also an area of much confusion for developers. There is a large amount of technology marketing about the best ways to develop web applications. Almost none of this marketing explains how web applications should manage data security and API integrations. In this article, I demystify some web jargon and show how the web and API sides of the architecture should interact to create a unified, secure architecture.

Modernization Requirements

Modernizing a web architecture means rethinking how technology, hosting, security, and integration patterns work together. It’s not just about updating frameworks — it’s about aligning with modern API-first architectures and strong identity practices.

Web Technology Requirements

For new apps, developers often choose a single page application (SPA) technology stack such as React or Angular. Instead of using SAML assertions, developers build solutions using the most up-to-date security standards, centered on the OAuth 2.0 Authorization Framework. The browser-based application receives an access token (AT) to send to APIs and a refresh token (RT) with which to silently renew it.

Although this technology update adds modernization, developers may follow insecure practices. Using tokens in the browser is considered less secure than the SAML solution. In some cases, the new app may fail security reviews and be unable to go live. Browser security is a hot topic for security reviewers, so any web modernization should first consider security modernization. You should also consider the crucial impact hosting has on the security and web architecture.

Hosting Requirements

Some older architectures, like SAML, had dependencies on legacy infrastructure. For example, you might need to store user accounts in Active Directory and use Windows Servers. Static web content does not contain secured assets, so it can use newer hosting technologies, like content delivery networks (CDN). For APIs and data, cloud native hosting usually provides the best technical control.

CDNs improve web performance by deploying static content to hundreds of locations so that the latency of requests is the same globally. Cloud native enables you to deploy APIs and data anywhere, perform phased modernizations, or take control over difficult requirements like data sovereignty, where you store user data in each user’s home region. These capabilities are often key goals when designing zero-trust, API-centric architectures.

Security Requirements

In 2025, your data security architecture should protect against many threats that can impact APIs, frontend applications, and users. You achieve the best protection when you apply the OAuth authorization framework while also following best practices.

For new web applications, pay particular attention to the latest security best practices from the OAuth 2.0 for Browser-Based Applications document. The main browser threat is cross-site scripting (XSS), a serious vulnerability that can expose sensitive data in many ways. For best protection, use the following approaches:

• Prevent and contain XSS exploits.

• Keep OAuth tokens out of the browser.

• Use hardened HTTP-only cookies as short-lived API message credentials.

• Prevent untrusted web origins from sending cookies to APIs.

You can perform a phased upgrade from SAML to OAuth with an identity and access management (IAM) system that supports both protocols. Start by repointing SAML apps to the new IAM system so that they continue to run as previously. At a suitable time, upgrade each SAML app to OAuth. This phased SAML-to-OAuth web modernization approach enables organizations to modernize their legacy web architectures without downtime.

Integration Requirements

Web development should be centered on the customer experience. There should be no need for web developers to run backend infrastructure that manages data security. Also, choose technologies that keep code bases modular, to support techniques like splitting large web applications into micro-frontends.

Another point to consider is that APIs are now the unit of reuse. Older practices like embedding webviews that render sensitive data into mobile apps or external web domains are no longer considered secure in the modern era, since browsers will not allow cookie sharing across domains. To scale UI architectures, organizations will need to develop views multiple times, in both web and mobile applications.

Web Architecture Styles

Unfortunately, many web modernizations produce suboptimal results. Developers make choices based on the latest technology stacks and their marketing. Online articles encourage the use of pre-rendering, client-side rendering, or server-side rendering, with little to no mention of data security. So let’s take a closer look at each of these styles from an API integration viewpoint.

Pre-Rendering

Organizations often have some frontend content that renders public data. For this content, you can use the architectural style of a blog or news site. Since all data is public, you can use technologies like NEXT.js to pre-render fixed content to HTML bundles without the need for the browser frontend to call APIs.

Pre-rendering is usually the optimal choice for unsecured web content. Deployments only need to upload HTML bundles to a CDN. The UI structure becomes HTML at deployment time, and the content is the same for all users. Pre-rendering performs well and can result in good search engine optimization (SEO) performance. 

Client-Side Rendering

Both mobile applications and SPAs can use client-side rendering. To do so, an app must initiate user authentication and get an API message credential. The app then calls APIs to get data and update its view model. UI elements are then created from the model. The following Swift code snippet demonstrates the approach for a mobile application.

return VStack {

    if model.data != nil {

        List(model.data!.transactions, id: \.id) { item in

            TransactionItemView(transaction: item)

        }

    }

}

The UI structure for sensitive data is unavailable until the frontend receives an API response and updates its model. You cannot pre-render the data since it varies by user, and it is not secure to pre-render sensitive data. Client-side rendering can work identically for web and mobile apps, which helps when you need to implement the same views on multiple platforms. 

However, some suggest that web applications should instead use server-side rendering (SSR). Let’s look at how SSR works to serve HTML containing sensitive data to the browser at runtime.

Server-Side Rendering

In the days of SAML, it was common to use SSR for secured data. To see an example, check out the SAML 2.0 example website. The web host uses SSR to combine HTML with sensitive data.

<ul class='list-group'>

    <% for (const item in model.transactions) { %>

        <li  class="list-group-item">Description: <%= item.description %></li>

    <% } %>

</ul>

In OAuth you should aim to use short-lived cookies in requests from the browser to backend endpoints, so that if a cookie is somehow intercepted, an exploit only lasts for a short time. With client-side rendering, JavaScript frontend code can handle expired cookies and perform a refresh operation. With server-side rendering, the web host has to return an HTML response if a cookie expires, which is difficult for the frontend to handle with good usability.

When you use SSR for sensitive data, you do not get the SEO benefits that pre-rendering provides, since internet searches cannot reach secured views. More generally, the fact that the web host and HTML responses use sensitive data adds complexity and unwelcome side effects.

Hidden Complexity

The SAML example website uses a runtime that enables cookie-based web sessions, server-side redirects, and server postbacks. A session store maintains the web state during these operations. For production deployments, the session store needs clustering and persistent storage. Many CDNs are unlikely to support running web backends with these dependencies.

Many OAuth website technology stacks continue to use this type of complex backend. In fact, complexity may increase when you integrate OAuth and APIs. The web backend needs to implement an OAuth code flow, translate cookies to tokens, route requests to APIs, process backend error and expiry responses, and write backend logs. Therefore, server-side rendering requires web frontend specialists to implement many backend data security concerns.

Often, web developers start with a website solution that implements security and then evolve their setup into a hybrid app. The main frontend might be a single-page application like a React App. However, the developer must also run and maintain a complex web backend for all future development. Over time, this overhead adversely affects the time to market.

Modern Web Security Design

A key design principle for building an optimal web architecture in 2025 is to separate concerns. In the API era, you only need cookies to transport access tokens to APIs, and any session-related data should be stored on the API side of the architecture. Since cookies are an API message credential that transports access tokens to APIs, you should think of them as an API concern, not a web concern.

Separated Web Deployments

You can combine OAuth web security best practices with the client-side rendering of a modern web technology stack if you use a backend for frontend (BFF) that runs on the API side of the architecture. You then use utility APIs to manage secure cookies. Doing so externalizes backend data protection, and all of its complexities, from the web side of the architecture. 

The token handler pattern separates concerns to provide a web security design for the modern era. Web developers only need a lightweight static content host and can focus on a frontend app that interacts with APIs. Deployed APIs include an OAuth Agent that gets tokens and issues cookies to the browser. An OAuth Proxy runs in the API gateway to apply web-specific protections during API requests.'

For some example frontend security code, see the SPA using Token Handler code example. This demonstrates a modern low-code approach where frontend developers do not run any backend infrastructure. The token handler pattern elevates the security of a browser-based application to the same level as a correctly implemented OAuth-secured website. In fact, it can exceed the security of older SAML websites.

Hardened Browser Security

Many older website technology stacks do not support the latest protections or may make it easy to misconfigure security settings. For example, they may use long-lived session cookies that increase the security impact of a stolen cookie header. 

By contrast,  modern implementations, especially those designed by security experts, can stay aligned with evolving browser standards. For example, if you migrate SAML apps to the Curity Identity Server, you can upgrade to OAuth by deploying the Curity Token Handler as a BFF. This enables a hardened setup that surpasses the security posture of most traditional websites:

• SameSite and CORS protections restrict cookie access to an SPA’s precise origin.

• A modern cookie encryption algorithm ensures confidentiality and integrity.

• Short-lived cookies (e.g., 15 minutes) reduce the impact of cookie theft.

• Pushed Authorization Requests (PAR) prevent browser tampering of OAuth requests.

• JWT client assertions provide strong backend OAuth client credentials.