SAML: A fractal of bad design
blog.trailofbits.com
blog.trailofbits.com
- check it against an hmac using a password specified in the attacker controlled document.
- check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)
I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.
It’s three entire specs bundled as one. One for the XML components, another for the documents you build from them, and another for the authentication flows built on top.
C. A. R. Hoare
I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex.
I think that hints at the problem space being... large and complex and requiring large and complex solutions.
What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.
Of course, SSL 2.0 did reference x.509, so hey, SSL 2.0 should have invented its own PKI. Except that Netscape might have come up with something terrible that worked in 1993 in labs but didn't scale to the web, or just full of security problems, or...
What you say sounds nice and right right up until you actually look at the details of what actually happened in real life, and how things actually evolve when they have little standards involvement.
Was the IETF PKIX WG "forcibly" shut down, or it merely concluded, with new WGs popping up to do similar things when needs arose?
First, anyone can participate. The only cost is the value of your time.
Second, yes, there are the usual suspects -- the ones who've decided to spend a lot of their time on whatever the area of tech we're talking about.
Third, working groups have charters that delineate what RFCs they will publish. Sometimes the work runs out. Sometimes the people run out of energy. Sometimes the tech is 'done', at least for a while. Then the WGs shut down.
Fourth, sometimes new work gets brought to the IETF in an area where the relevant WG has concluded, so then a new WG _may_ get spun up to take on that work.
Signed assertions. Signed messages. Encrypted messages. Encrypted assertions. Sign after normalization. Sign before normalization. Encrypt then sign. Sign then encrypt.
There’s too many ways to do too many things.
NB I can absolutely see why canonicalization is required... just that it was the bit where I lost interest
And that was before you got into deliberately malicious content that actively subverts the signature process.
They don’t build products, they don’t operate networks, and they don’t talk to customers.
HAIPE IS is classified, and mostly accommodates NSA’s private algorithms and key management practices.
IPMEIR is public, but it mandated the Suite B cipher suites and so I don’t know where it stands now with the move to PQC.
Specifying the algorithm in the attacker controlled document is a bad design imo.
Still i feel like SAML is much worse. JWT has a few rough edges, but SAML its like everything.
that said, algorithm agility isn't the primary issue, its whether you want symmetric (hmac) or asymmetric (digital signature). Both have advantages and disadvantages so there is no per-se right answer, it depends on context.
1. It has the ill-conceived "alg": "none". But this feature made breaking JWT so easy and low stakes, that many libraries have removed this feature completely, or just disabled it by default.
Modern RFCs that mandate JWT use in servers (e.g. RFC 9068) often explicitly forbid this, and the latest BCP for JWT (RFC 8725) recommends that libraries only accept or generate tokens with "none" when the user _explicitly_ requests that. And yet, we're still seeing "alg": "none" vulnerabilities even to this day. I'm not sure if it made sense to support "alg": "none" in the first place, but if we ended up doing that, the RFC should have been much more strict about this.
2. The other issue is mixing up asymmetric and symmetric encryption. You can't embed the HMAC password directly in the user-generated message; but if the library is not built securely, it would just treat the public key itself as the HMAC key when it gets an HMAC alg in the header. This makes forging tokens quite trivial if the library is misconfigured.
JWT is not nearly as bad SAML and its designers learned some important lessons (simpler base format, no canonicalization or embedded signatures), but this is still a design-by-committee standard that didn't properly involve. The full JOSE standard (including JWA) is even worse, but fortunately JWA doesn't get used a lot.
Been there, done that, wrote the stub/mock and ended up with the better test. :)
The article rightly connects this to XML, which was indeed the hammer to everything’s nail at the time
I think we aren’t done with this problem yet, though. OIDC makes a lot of assumptions in service to Google and others. And tailscale as mentioned, despite “holding the line,” already reveals the cracks when things like GitHub accounts have to be treated differently from others.
What we are missing is a provider-independent way to do this. I should be able to create an account and log in just about anywhere using a backend I control. It can be done, but not with what we have today
"Host your own identity"
Turns out, you can support Google and Apple accounts in your app, not the other way around. Well..
(Still a win though, especially if you need to gate your app with a login.)
Smaller tech companies don't want federated login to happen. They are, as a rule, far to happy to rely on the SSO tax to up-sell enterprise customers. The major authentication companies don't want federated login to happy because it invites more competitors and threatens their absurd margins.
Until someone manages to solve the business side, no amount of improved technology will change a thing. I'm pretty sure the few small interoperability gaps OpenID Connect has could be corrected in a matter of months if the stakeholders actually cared.
From vague memory, the other stuff in OpenID Connect was layered over the original OpenID identity verification part.
OpenID Connect is basically OpenID reimagined on top of OAuth 2.0, with using JWT for the identity data.
The core OpenID Connect spec is still purely a federated identity standard. There are many other standards pushed by the OpenID foundation, but OpenID Connect itself was never meant to be anything more. The main feature differentiator from the OG OpenID is that it's built on top of OAuth, so you can add other features supported by OAuth (like authorization) ad-hoc.
Who do you think would host the "federated login" system that would replace the major authentication companies?
You can already stand up a SAML or OIDC provider using OSS and run the IdP for your company. I have many customers that do! And you bet we still charge them for SSO, and that they're every six months asking how bad the migration to a "big auth company" would be.
I should be able to just give my email or domain name, and it kicks off an oauth flow to that domain no matter who I use for my email/identity. In the same way that I can give you my email address and you'll just email me without me having to pay extra for enterprise email.
IndieAuth exists, it's just not widely supported.
If you needed a serialized representation of structured data, I think it made engineering sense to use XML even if it was more featureful than you needed. The alternatives were ASN.1 or rolling your own format from scratch. It's not at all obvious that those are better.
(You could argue in favor of rolling your own format on the grounds that it wouldn't be vulnerable to XML-specific security problems, but I don't think those problems were fully appreciated at the time. If they had been, probably people would have come up with some kind of quasi-standardizable secure XML variant that just disables the specific features that cause those problems.)
I agree that XML (even without the security-relevant misfeatures) is worse than JSON or other non-markup-language serialization formats for the majority of use cases that don't need a markup language, but this is not a big problem, it's basically just syntax.
The DSIG problems are wildly worse than syntax! There's a document object model to contend with, along with invariably-fatal parser differential bugs, and that's before you confront the one global C implementation that almost every DSIG implementation ends up relying on.
We can’t change the past anyway, but ‘considering SAML harmful’ today may be the most reasonable position to take.
XML is deceptively simple-seeming, but it's not simple at all. JSON isn't actually trivial, mind you, but by comparison to XML, ASN.1/DER, etc, JSON is trivial.
The only reason to prefer ASN.1/DER here is that the likelihood of very badly broken libraries that fail to validate signatures becomes comparable to the same for x.509/PKIX certificates: fairly low due to the need for a whole ASN.1/DER ecosystem. It's the must-be-this-tall-to-ride effect.
To be fair to OASIS, in 2002 XML was textual and simple-seeming. It was the obvious choice. It must have seemed brilliant. They didn't know it would turn out badly.
Even with JSON you need solid decoders, excellent libraries, and you'll still want a JSON Schema and tooling.
XML Schema (just like JSON schema) did not. When we're talking about a "simple format" in terms of security we are talking about parsing footguns like these features, not about complexities that may exist with any wire format such as schema and data validation.
Were there any better formats for simple messages back in 2002?
I would argue that yes.
1. ASN.1 is horribly complex, but PKCS #7 (Cryptographic Message Syntax, a.k.a. CMS) was already established, and it was better than XML Signatures in one regard: it did not try to fuse the signed content with its envelope. But this probably wasn't he best choice.
2. If all you needed is a bag of keys and values, you could easily go with an RFC 822 style header + values format (which worked well for both email protocols and HTML). As a bonus S/MIME was already well established at this point, so you had an obvious way to sign this data.
3. Simple binary formats like XDR (used by NFS) or simple textual formats like LDIF or the RFC 822 header format mentioned above could be freely combined with any existing signature protocol that did not mandate structured data (i.e. every signature protocol in existence before XML Signature came in).
4. An even better approach of course, would have been to say no to fine-grained cryptographic agility[1]. That was a terrible mistake, but it was the default design choice back in 2002, and it's hard to single out OASIS. The JOSE/JWT authors should have known better though. You could have define a couple of ciphersuites/version, and a simple, fixed signature protocol for each version.
5. The best approach would have been to just avoid signatures completely and require TLS, but this wasn't viable back in 2002. Even OAuth 1.0 and OpenID 1.0, which came out several years later, included their own cryptographic signatures, but their schemes were still far simpler than SAML.
I think the key takeaway today is that SAML is no longer necessary today. TLS is not an option for secure web resources. There are no features of SAML that cannot be supported by OAuth or OIDC (only security misfeatures). All IdPs and most products support OIDC. In fact, OIDC is probably more well-supported than SAML.
SAML is only used because of enterprise inertia and self-inflicted FUD. As a professional, we should treat SAML with the the same disdain we've directed we've directed towards Internet Explorer 6. This is an insecure legacy technology that presents a drag on the entire industry.
---
[1] https://www.blockchaincommons.com/musings/musings-agility/
2. Yes, unless you need much more structure, then you have to think about ASN.1, XDR, PB, JSON, etc.
3. XDR is a perfectly reasonable basis for an ASN.1 encoding rules family. In fact, PER/OER resemble XDR in many ways. XDR is only simple because a) it's way simpler than the supposedly-simple tag-length-value encodings that ASN.1 came with originally, and b) Sun actually built a solid codegen tool (rpcgen(1)) for it. Never underestimate the value of having excellent tooling as a way of simplifying things :)
4. Alg. agility needs to be tied to the signing keys, not allowed to vary in the headers. Apart from that, you do need alg. agility, so its complexity can be minimized, but not made to disappear.
5. No, because TLS only establishes a channel between two entities, but here we have three or more entities: the two end-points of a TLS connection + all the trusted third parties. The trusted third parties need to communicate to entities they have no direct connection/channel to, and having those pairs of peers initiate connections to get those items is actually quite complex for reasons.
5. It really is the case that signed tokens are extremely handy and simpler than not having them -- it's just that getting signed tokens right has proved tricky in part due to advances in cryptanalysis exposing design mistakes no one knew they were making decades ago.
It’s like “using JSON” but actually encoding objects indirectly through your own made up object notation… that is structured.
If anyone could attest to who they are at any time we could just have user/pass without email and call it a day.
You've lost me here due to my experience with Kerberos and OAuth (JWTs specifically), though I mean JSON, not XML, so if by "marked-up" you meant "XML bad", well, that I would agree with.
Kerberos has something of a "markup" in that it has typed holes for carrying all sorts of useful metadata about the subject, especially what it calls 'authorization-data', but a) it's a real pain to get KDCs to include useful site-local things, b) it's remarkably harder to get Kerberized services to be able to get at that authorization data! (b) is surprising. I worked that problem for a bit -- I've done a lot of work on Kerberos, but APIs involve lots of work, not just C but Java, Python, all the things, so the last mile requires a ton of work to bridge, and then you end up with a pile of {some kind of data type ID, data encoded accordingly} that the application has to decode, so you have to:
- specify syntax/encoding for your site-local authz data
- write KDC-side code (preferably just plugins)
- implement RFC 6680
- including language bindings for various langs
- implement authz data decoders to use in apps
- use those decoders in those apps
Now compare to JSON: when you're done validating the signature or MAC, or decrypting the token, you now have a JSON text for the claims. Injecting site-local claims in your token issuer is trivial now. Using them in your applications is even more trivial (provided you have a JWT validator, otherwise it's too trivial if you forget to validate the signature!).
JWT got this right. Kerberos got it wrong.
In defense of Kerberos, it goes back to the mid to late 80s depending on which version you want to start counting at, and GSS-API goes back to the early- to mid-90s. So we're talking 30+ to 40+ years, all of it predating JSON and XML.
But today, in 2026, Kerberos is indefensible. Kerberos is still necessary, yes, because there are specs for and support in so many useful application protocols and implementations thereof, and because of Active Directory.
The lesson I draw from this is that GSS-API in the mid-00s needed to have grown a version of `gss_accept_sec_context()` that outputs a JSON text. I wish I could go back in time and build that.
So, yes, authentication context metadata, including metadata useful for authorization, can and should be represented in a "markup" language, specifically JSON.
At the time this “markup” concept got everyone all excited. But it ended up not being the way to solve problems like what you seem to describe, which don’t have the arbitrary document aspect at all.
Which is exactly my point. Markup and structured data are different. Even at the time of XML’s reign, there were plenty of established ways to serialize and exchange structured data.
Trying to solve a structured data problem with a markup language is how the markup language as a concept got contorted into a data structure system that was simultaneously both too flexible and arbitrary and too maddeningly rigid.
JSON solves it by being a data structure first and last.
But it does have the "arbitrary document aspect" when you add the desire for site-local claims.
> JSON solves it by being a data structure first and last.
I'd say that JSON solves it by being remarkably simpler than XML and by having become ubiquitous.
Your points about HTML... keep in mind that HTML is for humans, but what we're talking about here is for programs.
A new IndieAuth-like pattern is emerging for how to do this, based on the combination of OAuth, FedCM and DIDs.
OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.
I don't believe it's plausible for any non-specialist firm to implement SAML without grave vulnerabilities. I'm not sure I've ever seen it done well. It's been a minute since I've looked (I haven't consulted in several years, but, more importantly: most firms avoid SAML now), but I'm guessing that assertion still holds.
This isn't strictly a limitation of OIDC, but I do see this issue more often with OIDC implementations. With IdP-initiated flows, the app doesn't need to know who's in my IdP ahead of time.
But it turns out, all the major IDPs support OIDC now. It's a non-issue.
I think you're drastically overstating Tailscale's share and ubiquity in the market. Maybe it's heavily represented in tech companies or those in The Valley but among rank and file normal companies not dominated by developers, they've never heard of Tailscale
(It is good that they're not doing SAML, because SAML is the worst security specification ever written, and very few organizations have ever implemented it safely).
The best estimates I could find have TS at a 1-2% market share. And that was my point: You suggested "well if Tailscale can get away with not supporting SAML, anyone can!" and I think that's wrong. 98% of the market already is buying Tailscale's competitors, they can hardly do worse
I'm sure they can juice that a good deal more, but eventually they'll have to start picking off features that they have been avoiding to this point. Will that be SAML? Maybe not, most companies are on Entra ID which supports OIDC. The real tell will be when Tailscale either goes public or sells to private equity. When their backs are to the wall and they need to squeeze out another percent or two in growth and they have a big customer that must have SAML, then they'll do it
You're overestimating the importance of Tailscale, underestimating the importance of SAML to enterprises and completely skipping over the fact that the customer base that Tailscale has restricted itself to, probably doesn't use SAML to begin with.
Here, I'll share you my thoughts on Tailscale:
I don't use Tailscale. I don't care about Tailscale. I don't know what Tailscale is and I don't really care to know, but I know what SAML is and I know that I will keep using SAML for the foreseeable future, and I know I won't be using Tailscale.
"sine qua non" is hubris.
Pretty much every large enterprise (inc. half a dozen non-tech F500s) I've seen in the past 5 years has used either GlobalProtect or AnyConnect. Slightly further down the scale, you start to see some Prisma, Fortinet, or F5 as well. All of them support SAML, and market it as being a key feature.
Personally, I'd love to see Tailscale being deployed more widely, but I've only ever seen it deployed by tech companies.
IdPs that need to support an "IdP-initiated" user experience (like a portal or dashboard where users click an app icon) should instead have that icon link to a specific landing page on the SP that safely kicks off a standard, SP-initiated OIDC flow. IdP -> (SP -> IdP -> SP). Look at Okta's "Initiate Login URI" for an example of this.
The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.
This flow is safe against CSRF, since no authentication data is carried together with the flow. The only other safety issue I can see is using target_link_uri for CSF. The spec clearly mentions that this URL has to be filtered or ignored by the RP.
Instead of treating the (horrible) technical implementation as a feature, it addresses the real user-facing feature: I want to be able to click on a link on my IdP dashboard and be redirected to the app. The login would still be seamless, since you already have an SSO session active with the IdP.
[1] https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...
It's an easy solution, but it doesn't work at all.
For starters, users generally do not understand what a cert validation error means. They do understand what it means to browse to a website.
The cert validation error is in the way of the user's intended action. This popup would not be.
Fundamentally such a pop up is not a security warning. It does not indicate that something is unsafe. That makes a world of difference.
I think a better comparison would be when you exit an app, and the app prompts you if you want to save. That has generally worked well.
https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...
I think that's the real problem. Just tying up things with custom, system dependent configurations would probably be more predictable. Most people are probably happy to get the happy path running.
I mean … how else would you check a signature? You have to have the data to validate the signature.
In SAML you sign a (potentially attacker controlled) subset after normalization. So a lot of saml bugs come down to the attacker adding things that aren't covered by the signature. Sometimes this means appending or prepending stuff, but my favourite is adding comments which can alter the interpretation of the xml document (as it splits text nodes) but doesn't alter the signature.
It's an absolute dumpster fire.
So it is possible to have an XML signature that points to an element that does not include some important piece of data.
You would be shocked (or, if you’re in the security space at all, not even remotely shocked) to learn that a comical number of SAML implementations verified the signature and then just treated the whole doc as if it was trusted, even if the signed part had nothing to do with the document as a whole.
Email's in a bad situation with regards to this because every intermediate server is expected to mangle the message and the headers, so the only way to consistently sign something is to make it a marked up encoded block the way PGP does.
I used to maintain a legacy public IdP with a bespoke saml implementation that predated almost anything and was a nightmare to work with. I always wanted to migrate to one login. Luckily I left that job before embarking in such a nightmarish project.
You'd be shocked at the number of developers that believe C has no types.
Signals their ease to spit out incorrect information with confidence. That has no place in engineering.
You guys are in an awkward position where you are both the old grandpa and the new kid on the block simultaneously while there are competent middle aged workers around.
I use many languages. Some more than PHP. But that's besides the point.
I suppose you are more a fan of the histrionic tone of the criticism than anything? In which case, I'm with you there. It's equal to the most unhinged but technically correct rants of Zed Shaw for me.
It's a classic that everyone should at least know about and have read at least once.
As the post mentions, I worked on the DAG (an on-prem IdP implementation) for many years, which was based on simpleSAMLphp. So "PHP: a fractal of bad design" was our other north star after the SAML specs for avoiding critical security issues. I spent many hours poring over that blog post trying my best to avoid PHP bugs.
Here was a fun one that occurred due to PHP's wonky in_array behavior: https://simplesamlphp.org/security/201710-01
SAML can.
In general, SAML is complicated because (1) auth is complicated (2) XML is complicated (3) canonicalization/signatures are complicated.
Some of those are unforced errors, some are historical facts.
Why not? The flow can be entirely client side. OpenID discovery and PAR is optional and those would require direct connections
SAML does not require JavaScript to do that.
I'm almost convinced already, but I have the professional duty to at least read why
>SAML is an XML-based
Ok, I'm convinced
The committee had, at the very least, ASN.1. Not text, but any digital signature scheme has to be machine readable, not human readable.
A SAML lib needs an extreme amount of XML sanitization, while still handling all the various “in-the-wild” XML format funkiness
- personally, I like having a kitchen sink
Ideally you should use encrypted tokens so you're forced to do authenticated decryption before getting to the claims portion, but no one has bothered to build that in a way that scales. I did build something like this for Kerberos in Heimdal (https://github.com/heimdal/heimdal), but we need it for encrypted JWTs too: derive symmetric encryption keys from {current epoch, base key, audience/relying party name}, and let the relying party download those keys (by authenticating) much the way they do for signed JWTs. But switching from signed JWTs to encrypted ones is a pain as it requires that the issuer know if the relying party can handle it.
1. For OIDC/OAuth2 the request has to originate from Service provider, most Enterprise IDP's rely on SAML for Single Sign on cause of its ability to do IDP initiated flows
2. The security for SAML is baked into the payload itself, provides safety against MITM attacks, even though the HTTPS provides similar guarantees in theory, the reality is that your SSL offloading happens elsewhere, not on your application server
The OP provided a list of vulnerabilities discovered in SAML, IMO this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
At the end of the day, these are tools and effectiveness of a tool is a lot dependent on ones skillset to understand and use the tool.
This is just as true for JWT. Actually its a lot more true for JWT as people usually implement this wrong in SAML.
Additionally, https doesn't really protect you here, as typically the user sees the token/saml document, and they are the main party you have to worry about being in the middle.
> this kind of comparison if flawed if you do not present the same for OIDC/OAuth2.
i'm doubtful there are any vulns in oidc/oauth2 that aren't present in saml. SAML vulns are typically a strict superset of oidc vulns.
Anyone who has used Wireguard and OpenVPN will spot the difference. OpenVPN is the design-by-committee, Wireguard is the focused opinionated design by someone with a vision. OpenVPN does more things, but if your use case is one that suits Wireguard, Wireguard does it much better.
You also see it with OSI stack versus IP. OSI invented all these layers for proving identity, establishing circuits, sessions, different billing models, collect calls, quality of service, all that stuff. IP looked at that and said: fuck that noise - we send packets, if they don't arrive we send them again, job done. Nobody uses the OSI stack, even though IP fits the OSI model loosely enough that they still teach it, and X.509 got reused as boilerplate for WebPKI certificates.
XML vs JSON is another one. Granted marked-up text, which XML was actually designed for, is very ugly in JSON, but even in that use case, XML has way too much complexity.
If the IP, Wireguard or JSON people designed an SSO system you'd telnet or HTTP into the authenticating party, perform its login steps, get a token you could copy-paste into the relying party and it would check back with the authenticating party to see if the token is valid and the username of the person who signed in - done. And then someone would make a browser extension to automate the copy-paste part. Or maybe they'd embed it in an iframe. Instead we got whatever the hell this is.
Protocol complexity is where bugs hide, including vulnerabilities. It also creates incompatibility wherever two implementations implement it differently - and that's intentional in many cases. It's just bad. You have to be opinionated about what you design or you designed nothing at all. If it doesn't fit all use cases you can design something else to cover the rest.
We should remember that we learn by failing.
Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.
Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.
The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.
That is a workable if coarse description of OIDC, which kind of fits your SAML vs. OIDC framing, although I’m pretty sure that’s not what you meant to imply.
The difference between IP and the OSI stack is the standards development organizations: IP was specified in a fairly unofficial way (RFCs) by academics via email in what eventually evolved into the IETF, while OSI was specified by ISO. ISO is much more difficult to work in than the IETF. But there are still specifications behind IP. It's not 'just send a packet and see what happens'.
> Protocol complexity is where bugs hide, including vulnerabilities.
You can't make that go away. TCP/IP is not a non-protocol. The best you can do is minimize that complexity.
(Or to be more clear, it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with. You either work with what we use or you are not viable as a product for our need. It's kinda simple. I would expect someone whose authentication was OIDC-based to be similarly dismissive if you told them you only would do SAML.)
Pretty much everything supports SAML. If you decide not to support one of the standard protocols for SSO, you'll lose out on customers. Your tool has to bring in a lot of benefit (and have no competition) to warrant upending a company's entire auth system for.
Makes sense for GP locally, I guess, but globally we’re all worse off when nobody is motivated to break free from the path of least resistance.
1. "You either work with what we use" - so whatever organization you represent isn't capable of evaluating and shifting to more secure technologies?
2. "it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with" - you think companies that care about security should not care about integrating with flawed protocols?
A potential customer making bad choices does not obligate a business to make bad choices for their business.
As a SaaS vendor, interacting with our customers about SAML usually involves:
a) them knowing what they want because they already have SAML-based SSO and it works for them; and
b) our contact on their side being some unfortunate support dude who got given SAML as their subject area for whatever reason, and who knows very little about it, and who is 4 levels in the org away from anyone empowered to make decisions as significant as moving away from SAML.
1. Finding out a company wants several grand to flip the "allow SAML" switch on the tenant config, and a few thousand a year in additional licensing to leave it on. (I had a vendor both tell me it "takes five minutes" to get it set up, and then quote me $4,800 to "implement" it.)
2. Having to yell at the SaaS vendor for routing the identity connection between two or three other identity providers in different various clouds because, you know "modern stuff". (A vendor I am working with has not less than five different accounts to access various parts of their infrastructure, none of which are connected at all. I assume people there listened to "switch to OIDC" nonsense, completed half the job, and now have OIDC sites and SAML sites forever.)
3. Discovering the SaaS vendor knows how Entra works, how Okta works, and how Google auth works, and having no idea how SAML works. Or OIDC or anything else for that matter.
4. Eventually finding an engineer far enough from the sales and implementation teams who can answer how the product actually works. :D This point is reached after a lot of yelling.
If I’m paying for at least one Senior to build and support this awful enterprise authentication pattern, I’m looking at around 200k per year in total cost - you damn well bet I’m billing you for it!
Im sorry if your UK salaries are much smaller, but I’m not P Diddy taking anyone’s piss out here m8!
Indeed it does not. If you feel that strongly that you are willing to lose out on that customer, that's your right. But that does not mean the foregone customer is unreasonable for expecting you to work with their constraints in order to get their business.
Saml is just not reasonable in our modern security environment.
https://www.war.gov/News/News-Stories/Article/Article/428899... (Microsoft has solely discontinued this practice for the DoD tier. Commercial, GCC, and GCC High are still impacted because foreign labor is cheaper than the risk to your security.)
And a key aspect that modern setups often forget: Every single different UI your users see makes them easier to phish. One of the reasons Entra is so easily phishable is Microsoft uses like 500 different domains for their cloud platform, so the one in the mix they don't actually own isn't obvious to the average user.
If you are a vendor, you should have SAML support unless you are early (and can only support 1 standard), or you are highly opinionated.
If you are a consumer instead, you will only be using one standard, so you HAVE to chose 1 and not the others.
There is one valid excuse for why you must have support for an outdated protocol: embedded / air-gapped systems. For anything else, just admit that you don't want to make the change. That's a business decision, nothing else.
I think HN would do really well if we took this in the more general sense (any product).
If the customer is asking really hard for something, maybe you should just take their money and move on. Forcing 100% of your customers to adopt or endure weird technological ideologies is not a path to happiness.
If SAML is taking you so much effort to implement that its complicating your sales & development process, you are either using the wrong tools or the wrong developers. It should not be this difficult if you make a genuine effort.
I am often reminded of this particular meme template when it comes to HN and the customer: https://knowyourmeme.com/memes/baton-roue
The XSW part of the article was new to me though and kinda shocking
If my security system is showing friction when there's a wave of agentic slop, I'd say that's a win.
OAuth/OIDC is a problem if you're trying to shove a bot-shaped peg into a browser-shaped hole, but we don't need a new protocol to solve that.
Oauth2 is utter utter shite as well.
Neither does OIDC: "The methods used by the Authorization Server to Authenticate the End-User (e.g., username and password, session cookies, etc.) are beyond the scope of this specification."
OAuth makes zero assumptions about a lot of things, like even how you "authorize". That doesn't mean that authentication doesn't play a crucial role. While it doesn't specify how you authenticate the user it still specifies that you must authenticate the user. Outside of the authorization code flow, other flows strictly mandate that you should authenticate the clients.
1. It's not an authentication protocol, but it was abused as one for until OpenID Connect came along
2. OpenID Connect is the compatible authN protocol, and it actually has a spec unlike OAuth2
Both of those are annoying because they are over-complicated for simple use cases and for a long time there were very few simple open-source providers that weren't hiding all the important stuff behind their enterprise/cloud versions.
Open source options like Zitadel are improving this space somewhat, though they are still sort of painfully complicated if you want to deploy something small and simple that you can understand. In order to be big business they have to support tons of 3rd-party provider plugins with all their out-of-spec wrinkles.
It would be nice to have something like Zitadel that is signficantly less concerned about all those third parties - like let me very easily just host username/password and passkey auth in a small package.