DEV Community: Curity

Modernize SAML Web Architectures the Right Way

Maria Pelagia — Wed, 03 Sep 2025 00:00:00 +0000

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.

OAuth: What Everyone Should Know

Maria Pelagia — Wed, 23 Apr 2025 00:00:00 +0000

When you work as intensely with a certain technology as my colleagues and I do, you get a clear picture of how it works and should work. At some point, you realize that you have become an expert in your field; in our case, it’s OAuth. This is also the point where things that are obvious to you are not for others.

Securing API access is part of data security

OAuth enables integrated solutions between users, clients (applications), and APIs. OAuth systems provide the client with an access token with restricted API access. Although there are many guides on OAuth, they are commonly limited to retrieving the access token. As experts, we know there is much more to OAuth than sending the right protocol messages.

We found that there was a gap in the specialist literature around providing organizations with the strategies to integrate OAuth in particular ways so that security facilitates (modern) technologies and meets developer experiences. We realized that to make the internet a safer place, we needed to make our know-how available to the broader community. Slowly but surely, the idea of a book was born.

We decided on the title “Cloud Native Data Security with OAuth.” Some people may think the title is controversial because OAuth is all about securing access, while data security tends to be about securing data storage and encryption. However, this is exactly the pattern that we want to disrupt. You cannot talk about access control and authorization without also considering the data you want to protect. The goal of OAuth is to protect data (authorization) that APIs expose. It focuses on cloud native because it allows us to recommend solutions you can run anywhere.

Authentication is secondary to authorization

In OWASP’s top 10 API security risks list, broken authorization takes the front rank. It means that you need to secure access beyond simply authenticating users because your attackers may already have logged in, e.g., via stolen or compromised credentials.

Of course, securing the authentication process is part of the game. However, authorization is not the primary concern because authorization is about granting the least privileges to (authenticated) users. Newcomers to OAuth often focus on user authentication. Many misunderstand that the heart of OAuth is the content of the access token that should enable APIs to enforce least privilege access.

For data security with OAuth, you should rely on identity attributes when evaluating access control policies. For this, you should map scopes to a certain set of identity data to model the access token. The access token and related data are the source for APIs to enforce access rules. This approach combines token-based with attribute-based access control and provides a good foundation for an API security architecture.

A good access token design is essential for API security. Therefore, we devote a whole chapter to access token design, so that you can scale the use of access tokens to many APIs and clients.

There is more to access tokens than their attributes. The API gateway, for example, plays a vital role in an API security architecture with OAuth, as it provides the public interface of an API. The API gateway can compensate for client-application specifics so that you can implement a unified approach for access controls in API services. Having one way to do things simplifies development and, as a result, reduces vulnerabilities.

Cloud-native technology gives you many choices

The cloud-native aspect of the book focuses on choices like where you store identity data, the components you can use, and where you can operate OAuth. For example, it highlights how to integrate workload identities in an OAuth architecture to strengthen credentials.

The book lists best practices for client applications to address the weakest links in the security chain. It provides guidance and examples on implementing OAuth in browser-based and platform-specific applications (“native applications”), covering desktop and mobile clients.

The cloud native focus enables us to provide code examples that show how to run end-to-end OAuth flows with exactly the same technologies on local computers and cloud deployments. In the last chapter, the book discusses how to fortify authorization with strong authentication to improve assurance in the identity attributes.

In the end, implementing data security with OAuth is all about the attributes — the characteristics you provide to gain access to data. This is very apparent to us, but we found this message was missing in the OAuth-related literature. We filled the gap with Cloud Native Data Security with OAuth so that more people can utilize the building blocks OAuth provides and combine them with cloud-native technology to protect business assets in a secure and scalable way.