The Enterprise Paradox: Why we still use XML in 2025

It's 2025 and we are still arguing about xml tags while the rest of the world has moved on to json and sleek oidc flows. You'd think a tech stack from the early 2000s would be dead by now, but in the world of enterprise identity, saml is basically the cockroach that won't quit.

Honestly, it’s a weird paradox. We love to complain about how "heavy" or "verbose" saml feels compared to modern stuff, yet it remains the undisputed king of the b2b world. Why? Because when a ceo at a massive bank or a healthcare giant signs a contract, they don't care about your "modern" api-first approach—they care about their existing okta or microsoft entra id (formerly azure ad) setups.

The reality is that enterprise readiness isn't about using the newest shiny tool; it's about meeting the customer where they actually live. Here is why we're still stuck with xml:

• The Procurement Wall: If you're trying to sell to a fortune 500 company and you don't support saml, you aren't getting past the security review. It’s a "check the box" requirement that literally kills deals before they start.
• Battle-Tested Stability: According to OneLogin, saml was built specifically to solve cross-domain authentication issues that older cookie-based sso just couldn't handle. It’s been poked and prodded for two decades.
• Attribute Mapping Power: Enterprises need to pass more than just a username. They’re sending roles, departments, and cost centers. saml assertions are like a "sealed envelope" of data that handles this complexity better than a basic jwt often does.

I've seen this play out in everything from retail to finance. A large hospital system won't just "trust" your new app; they want to externalize authentication to their own idp so they can kill access the second a doctor leaves the practice. As Descope points out, this removes the burden of password management from the app developer entirely.

While some older reports had wilder numbers, current market data suggests the broader Identity and Access Management market—which saml dominates for enterprise—is growing steadily at a CAGR of around 13%, proving this "legacy" tech isn't going anywhere.

But saml isn't just about logging in—it's about the trust handshake that happens behind the scenes. Next, we'll look at how that actually works under the hood.

Deconstructing the SAML 2.0 Handshake

Ever wonder why your browser does a weird little dance of redirects when you click "Login with SSO"? It’s basically a high-stakes handshake where three different parties have to agree on who you are without actually sharing your password.

In the saml world, we talk about the Identity Provider (IdP) and the Service Provider (sp). But the real unsung hero is the User Agent—aka your browser.

• The Browser as the Mule: Unlike modern oidc flows where servers might talk directly, the actual authentication flow in saml is almost entirely indirect. The sp and IdP never actually speak to each other during the login. Instead, they pass signed xml "notes" back and forth through your browser.
• Deep Linking and relaystate: If a doctor in a healthcare system clicks a link to a specific patient record in a third-party app, they don't want to land on a generic dashboard after logging in. We use a parameter called relaystate to keep track of where the user was trying to go before the auth redirect interrupted them.
• Security through Redirection: Because the sp never sees the user's credentials, the attack surface is tiny. The user types their password into their own corporate IdP (like Okta or Microsoft Entra ID), and the sp just waits for a signed "thumbs up."

When that xml finally hits your endpoint, it’s a big, messy envelope. According to WorkOS, saml is built on xml, which makes it more verbose than json, but that "heaviness" is what allows it to carry so much metadata.

Inside, you’ll find Assertions. These are statements from the IdP saying, "I know this guy, he's an admin, and he's in the Finance department."

1. Authentication Statements: These prove the user actually logged in and tell you how (e.g., did they use mfa?).
2. Attribute Statements: This is where the gold is. You get the email, roles, and maybe a cost center. It’s why enterprise provisioning feels so seamless.
3. The X.509 Signature: This is the most common place where devs mess up. You have to validate the signature using the IdP's public certificate.

Watch out for Assertion Wrapping: This is a nasty attack where a hacker injects malicious xml nodes into the message. If your parser is weak, it might get confused and read the fake "admin" node instead of the real, signed content. This is why we use battle-tested libraries—they're designed to ignore any unsigned junk and only trust the canonicalized, signed parts of the xml.

As Okta points out, the sp doesn't even know who the user is until that assertion comes back. It's a "trust but verify" model where the verification step is everything.

Honestly, if you're building this from scratch, just don't. Use a library. Handling xml namespaces and canonicalization manually is a great way to end up in a security post-mortem.

SAML vs the World: Mapping the Auth Landscape

So, you're looking at the auth landscape and wondering why we have multiple "standards" that don't always play nice together. It's easy to get confused when everything is just an acronym.

The technical differences are what really matter here. While oidc uses json web tokens (jwt) and relies on simple http headers, saml uses the heavy xml soap-style transport. This makes saml much better at carrying complex "federated" trust—where one organization trusts another's entire directory structure—whereas oidc is often more "chatty" and requires more back-and-forth server calls.

• Transport Layers: oidc is built for the modern web and mobile apps, using restful patterns. saml is more of a "document exchange" protocol.
• Token Formats: saml assertions are way more flexible for deep metadata than a standard jwt, which can get bloated and slow if you cram too much in there.
• The "OAuth is Auth" Myth: Don't fall for the trap of thinking oauth 2.0 is an authentication protocol. It's for authorization—giving a third-party app permission to access your data. OIDC is the identity layer that sits on top of it.

I've seen devs try to force oidc on a bank just because they hate xml, only to realize the bank's idp only speaks saml. It’s about technical compatibility with their existing infrastructure.

Next up, we’re going to look at the "Procurement Wall" and why your sales team is probably screaming for this integration right now.

Scaling the Procurement Wall

If you want to move from $50/month customers to $50,000/year contracts, you have to climb the procurement wall. This isn't just about code; it's about business requirements that the big guys won't budge on.

• Centralized Control: Large companies need to be able to turn off access for 500 apps at once when an employee leaves. If your app has its own password database, you're a security liability.
• Compliance Boxes: Auditors for SOC2 or HIPAA often demand that all logins go through a central, audited gateway. saml is the standard way to prove you're doing this.
• The "SSO Tax": You've probably seen the websites that list which companies charge extra for sso. While controversial, it exists because enterprises are willing to pay for the security and management saml provides.

Building your own saml service from scratch to scale this wall is basically a rite of passage that nobody actually wants to go through. It starts with "how hard can xml be?" and ends with you crying over x.509 certificate rotation at 3 a.m. on a tuesday.

• Maintenance Hell: certificates expire, idp metadata changes without warning, and every new enterprise customer has a slightly different way of mapping "department" to "dept_name".
• Centralizing complexity: instead of writing custom logic for every customer using okta or microsoft entra id, you should be looking at a single api-first integration.

If you're going to do this right, you need to think about what happens when things break. Because they will. I once saw a retail giant lose half their workforce's access because an admin accidentally deleted a public key.

1. The Admin Backdoor: you absolutely need a "break-glass" login. Having a secret sign-in url that bypasses saml is a life saver when the idp goes down.
2. Automate or Die: don't let your support team copy-paste xml metadata files into your database. Use tools that allow customers to upload their own idp metadata.
3. Monitoring is key: watch your saml tokens for weirdness. If you see a sudden spike in failed assertions, it might not be a bug—it could be a credential stuffing attempt.

Post-Implementation: Surviving the Security Audit

So you finally got the saml flow working and the sales team is happy, but now the real fun starts. You've got a security audit coming up and some giant bank wants to know if your auth is actually "enterprise-grade" or just a pile of xml hacks.

First thing is mfa. Even if your app doesn't have a native mfa prompt, you should be enforcing it at the idp level. The beauty of saml is that you offload the "how" of auth to the customer. If they use hardware keys or biometrics, that's their business—you just need to make sure the assertion proves it happened.

• Auditing Assertions: Log everything. You should know exactly when a user logged in, which idp they used, and what attributes were passed.
• The Logout Problem: saml logout is notoriously flaky. To do it right, you need SLO (Single Logout). This requires a back-and-forth dance where the sp sends a request to the IdP, which then has to ping every other service the user is logged into to invalidate their sessions. It's so complex that many teams just skip it and use short session TTLs (Time To Live) instead.
• Trust Establishment: While the login flow is indirect (via the browser), you should use a metadata url for configuration. This is a direct, out-of-band way for your server to fetch the latest keys from the IdP. It's much better than manual uploads because it handles key rotation automatically.

I've seen a healthcare provider fail an audit because they didn't rotate their public certificates. Don't be that guy. Use a metadata url that updates automatically so you don't have to manually swap keys at 2 am.

At the end of the day, saml is still winning the b2b war because it's the only language the big players speak fluently. It’s verbose, it’s old, but it works. Stick to the standards, don't hand-roll your xml, and you'll be fine.

*** This is a Security Bloggers Network syndicated blog from SSOJet - Enterprise SSO & Identity Solutions authored by SSOJet - Enterprise SSO & Identity Solutions. Read the original post at: https://ssojet.com/blog/architecting-enterprise-readiness-saml-b2b-auth