Is SAML still relevant today?
TL;DR
The state of authentication in the modern era
Ever feel like every time we try to kill off old tech, it just digs its heels in deeper? I’ve spent years setting up sso for everything from tiny shops to massive banks, and honestly, saml is the ultimate survivor.
People keep saying oidc is the future, but walk into any hospital or a big finance firm and you’re gonna see saml everywhere. It's not just "legacy" junk; it’s the backbone of how these places talk to each other.
- Enterprise footprint: Big companies spent a decade building their identity systems on saml. (Why Identity Automation Fails at 96% of Organizations) They aren't gonna rip that out just because something shinier came along.
- Complex assertions: saml uses xml which is a pain to read, but it lets you pack a ton of user data into one token. (SAML Explained in Plain English - OneLogin) This is huge for industries like healthcare where you need to pass specific certifications or roles.
- B2B reliability: When two different companies need to share access, the saml toolkit is still the gold standard for stability.
According to the 2024 Thales Digital Trust Index, a lot of businesses still struggle with managing multiple identities, which is why sticking to proven standards matters.
In a retail setup, you might use saml to let store managers access a third-party inventory tool without a new password. It just works.
Let's look at how saml stacks up against the newer kids on the block when you're actually building stuff.
Comparing saml vs oauth integration
So, you're trying to figure out if you should stick with saml or jump on the oauth bandwagon? It's kind of like choosing between a heavy-duty truck and a nimble electric scooter—both get you where you're going, but you wouldn't use a scooter to haul a ton of bricks.
I've seen plenty of teams get frustrated trying to force one into the other's territory. Honestly, the "vs" in the title is a bit of a lie because most of the big deployments I've worked on end up using both.
Here is the deal. saml is great for that "one login to rule them all" experience on a desktop browser. It’s built for trust between big entities. oauth (and its buddy oidc) was born because mobile apps and apis needed something that didn't involve hauling around massive xml blobs.
Wait, I should clarify—oidc (OpenID Connect) is basically the identity layer that sits on top of oauth. While oauth handles the permissions (authorization), oidc provides the "ID Token" that actually tells the app who the user is. Without oidc, oauth is just a key to a room without knowing who's holding it.
- saml is the "Passport": It’s a heavy document that says exactly who you are. It’s perfect for a corporate lawyer in a finance firm accessing a secure portal. It handles the Authentication part—proving identity—incredibly well for web apps.
- oauth is the "Valet Key": It’s about Authorization. It gives a specific app permission to do stuff on your behalf (like a fitness app posting to your social feed) without giving away your actual password.
- Mobile vs. Web: Try getting a saml stack to work smoothly in a native mobile app without a messy browser redirect loop. It’s a nightmare. oauth was built for this, using light tokens that don't choke your bandwidth.
According to the Okta 2024 Business at Work report, while oidc is growing fast, saml usage remains steady because it's so deeply embedded in the b2b world. (Architecting Enterprise Readiness: Why SAML Still Wins the B2B ...) You just can't ignore that footprint.
In a real world retail setup, a cashier might use saml to log into the main hr portal on a PC. But the inventory app on their handheld scanner? That’s probably using oauth to talk to the back-end api.
Moving on, we need to talk about keeping these setups from blowing up in your face.
Security best practices for saml in 2024
Setting up saml is one thing, but keeping it from becoming a backdoor into your network is a whole different ball game. I've seen too many "secure" setups fall apart because of a simple copy-paste error in a config file.
Most breaches don't happen because the protocol is broken, they happen because we're human and we miss stuff. One of the biggest killers is XML Signature Validation. If your service provider isn't actually checking that the assertion was signed by your IdP, anyone with a text editor can spoof a login.
- Certificate Rotation: Treat your saml certificates like milk—they go bad. I've seen entire hospitals lose access to records because a cert expired at midnight and nobody had the admin password to the idp.
- Assertion Encryption: Don't just sign the message; encrypt it. This keeps sensitive user attributes away from prying eyes if someone is sniffing the traffic.
- Validation Tools: Use something like SSOTools to validate your assertions. It's a free way to check if your xml actually follows the rules before you go live.
According to a report by Veracode, a massive chunk of applications still ship with high-severity flaws in how they handle third-party integrations. It's a reminder that "plug and play" isn't a real thing in security.
In a finance firm, you might have a saml link to a trading terminal. If you don't enforce Strict Audience Restriction, a token meant for a low-security app could be reused to get into the vault. Basically, Audience Restriction is a setting that ensures a token is only valid for the specific application it was intended for, so it can't be "replayed" elsewhere.
Now, let's talk about how we're using new tech to manage this old-school xml mess.
The impact of ai security tools on SSO
Let's be real, managing sso logs is a nightmare when you're staring at thousands of lines of xml. I've spent way too many late nights trying to find that one "replay attack" or a weird login pattern that just didn't look right.
Now, ai security tools are actually making this bearable, especially for saml. Because xml is so verbose and complex, it's easy for a human to miss a tiny change in an assertion that indicates a spoofing attempt. ai is great at catching those tiny anomalies in the xml structure that shouldn't be there.
- Automated threat detection: ai looks at the "context" of a login. If a retail manager logs in from Chicago and then ten minutes later from London, the system flags it before they even finish typing.
- Managing the XML mess: These tools can scan your saml metadata and alert you months in advance before a certificate expires, saving those hospital admins from a midnight crisis.
- Predictive patterns: It learns what "normal" looks like for your finance team. If someone starts hitting the api at 3 AM on a Sunday, it'll notice the outlier.
A 2023 report by IBM found that organizations using ai and automation in security saved nearly $1.8 million in breach costs. It’s a huge deal for keeping your identity stack tight.
Since we've been talking about xml so much, we should probably address why developers are always complaining about it compared to json.
The XML vs JSON showdown
If you ask a dev which one they prefer, they're gonna pick json every single time. It's just easier to read. saml relies on xml, which is "heavy"—it has all these tags and namespaces that make a single token look like a whole book. oauth and oidc use json (specifically JWTs), which are much smaller and easier for a browser or a phone to parse.
But here's the catch: xml's complexity is also its strength in the enterprise. It has built-in support for digital signatures and encryption at a very granular level. json is getting there with things like JWS and JWE, but saml has had these "heavy" security features baked in for twenty years. Developers might hate the syntax, but architects love the robustness.
Final verdict on saml relevance
So, is saml actually dying? Honestly, I’ve been hearing that for five years and yet here we are, still troubleshooting xml signatures on a Friday night.
The truth is that while oidc is the cool new kid for mobile apps, saml is the grizzled veteran that keeps the enterprise world from falling apart. It’s not going anywhere because it handles the messy, "heavy" stuff better than almost anything else.
The industry is definitely moving toward passwordless flows. We’re talking about using biometrics or hardware keys to stop phishing in its tracks. Even with these shifts, saml stays relevant because it acts as the "bridge" for these new methods to talk to old corporate apps.
- Persistent Legacy: Big institutions like banks or government agencies have saml baked into their dna. They won't rip it out because the risk of breaking a critical login is just too high.
- Phishing Resistance: Modern saml setups are integrating with fido2/webauthn. This means you get the stability of the old protocol with the security of the new stuff.
- Cybersecurity Hygiene: Staying updated with news is key. According to a 2024 report by Verizon, stolen credentials are still the top way hackers get in, so your sso config—whether it's saml or oidc—is your first line of defense.
"The goal isn't to pick the newest protocol, it's to pick the one that your team can actually secure and manage without losing their minds."
If you're at a retail chain, you might use oidc for your customer-facing app but keep saml for the backend tool that manages employee payroll. It’s all about the right tool for the job.
Basically, don't delete your saml toolkit just yet. You're gonna need it for a long, long time.