My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also:
- 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.
I saw multiple implementations that looked for a signature, verified it, then just trusted the document as a whole rather than only the part that was signed. So as long as you had any signed SAML doc, you could provide an attention of your choosing and just bundle the signed one somewhere arbitrary inside of it.
It’s also enormous, I assume from the attempt to have nominally composable parts that could be reused for other flows.
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.
It is truly surprising how large the specs for each of these ecosystems are: PKI, Kerberos, TLS, OAuth, SAML, etc. They are gargantuan, especially when you include essential dependencies like DER codecs and ASN.1 compilers (PKI, Kerberos) or XML (SAML).
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
The problem with this is the assumption that there's a simpler way to do all of this, and if only we could stop looking for large and complex solutions we could just land on the simple ones.
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.
The thing is that they don't have to be that big at all, you could probably specify enough of PKI and TLS and SSH to cover most uses cases in, I dunno, 30-40 pages. However the standards bodies that produced them, termed "working groups", are more like standing committees that will (a) standardize any random idea that any member brings along and (b) are worse than the energizer bunny, they just keep going and going and going and going. Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS). You can't stop these standards mills, they'll just keep grinding out more stuff that no-one ever asked for, for all of eternity.
It sure sounds like it should be like this, but when you actually try you end up with not this. TLS is huge! Yes, but SSL 2.0 was smaller, and buggy as hell, so it had to evolve, and after 30+ years it became the monster that it is today.
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.
Well, no-one held a gun to their head but there was a general "enough, already", aided by the fact that several of the main characters were retiring which helped wind it up. And then they just kept going as before under a new name and with an influx of new people who were unaware of how the original mess was made and why.
So if a WG is wound up and then continues under another name with mostly the same people doing the same things the original WG did it's not really wound up, is it? It's just changing the sign over the door with business continuing as usual.
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.
The root problem with SAML is there’s a million and one permutations to do the same thing.
Signed assertions. Signed messages. Encrypted messages. Encrypted assertions. Sign after normalization. Sign before normalization. Encrypt then sign. Sign then encrypt.
That's because its built in part on XMLDSig, a genius idea to sign active content that can redefine its own semantics as it's being signed/verified. It's a triumph of ideology over common sense.
The first book that came out on XMLDSig, "Secure XML: The New Syntax for Signatures and Encryption", written by the chair of the working group, spent over half of its 500 pages wrestling with canonicalization, and even then it read more as a 250-page problem statement than a solution.
And that was before you got into deliberately malicious content that actively subverts the signature process.
I say this a lot, but: there was a conspiracy theory that NSA had infiltrated the IETF during the original IPSEC standardization effort and injected the "TLS BEAST" CBC IV chaining vulnerability, which is funny because we actually know exactly how that happened (professional academic cryptographers took out a petition to get the bug fixed and were shouted down by standards body gadflies who literally rejected the premise that there was such a thing as a professional academic cryptographer). This is really easy to see once you've done an engagement on DSIG security! Standards bodies are more than capable of fucking things up entirely on their own. If anything, NSA would risk making protocols stronger by intervening in their natural processes.
"Never attribute to malice what is adequately explained by stupidity". Or, in this case, design-by-committee by a bunch of people who haven't written ten lines of code in as many years. There have been several other cases where absolute no-brainer fixes, like one or two lines of code changed, to long-standing security problems, were filibustered, or blocked by WG chairs, for no explainable reason, and they can't all have been paid by the NSA to do that.
Yes, absolutely. And it's self-selection for mediocrity, people who are useless at any other task and prepared to argue endlessly over pointless technicalities that no-one apart from other professional meeting-goers care about are perfect for dumping onto standards committees.
This is a pretty common implementation error. You can just add your own assertion that overwrites any claims in the signed assertion (such as username) and use it to escalate privileges or take over any account that you like.
JWT has two out of the three issues mentioned above:
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.
Yeah I wanted to use alg none for some unit tests once (it was easier than setting up the next lowest tier security option) but whichever Java library I was using had completely disabled it. I could see it had been supported at some point but it had been updated so that it couldn't be enabled at all.
Yeah, the standard should have just specified like a sha256 HMAC, when that becomes broken in 20 years we can just do a JWT2 (or invent some new successor standard)
given that md5-hmac isn't even broken despite md5 being broken, it seems unlikely sha256-hmac will fall in 20 years.
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.
Yes, but you shouldn't be taking instruction on how to verify the security of a JWT from the JWT itself in the first place. Don't follow an attacker's security steps.
It’s such a product of “Ooh! Markup languages! What can we use a markup language to solve!” When authentication is just not a document or data stream that needs marked-up.
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
OpenID Connect actually has all the machinery needed to support federated login as part of its dynamic discovery and dynamic registration specifications. The issue is that absolutely no one uses them or implements them.
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.
As someone with a vested interest/being/been many of the parties you mention... Do you think support for "federated login via OIDC" would _not_ fall under the SSO tax?
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.
With dynamic client registration, I could host my own IdP server at home, or with a provider of my choice, and it would just work everywhere without any coordination work for anyone, manual signups to be assigned a client id/secret, etc. The entire point is that you won't let me do that because you want to charge extra for better, simpler, cheaper security for everyone. That is the SSO tax.
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.
There is nothing left from the OpenID 1.0 and 2.0 protocol in OpenID Connect, except for the core features (identity federation, identity information encoding and updates).
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.
Federation sounds like decentralization to me. Decentralized is like a dirty word when you’re in the business of either selling SaaS or pushing private citizens to go all in on the GOOG/AAPL/MSFT ecosystems. And everyone with any influence over what gets adopted and used, is in those categories.
They are being used. Workload Identity Federation is often used to assign oidc identities to workloads and the Client ID Metadata Document (basically dynamic client registration) is used in protocols such as MCP and atproto
As the article points out, it's not really fair to criticize SAML for not using JSON, given that JSON barely existed at the time.
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.
I don't understand this definition of "fair". Things are either good or they're not. Signed XML is not good. That's a fair claim, even if the designers of XMLDSIG didn't know as much as we do.
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.
My comment was aimed at the particular critique I was replying to, namely, that using XML for ordinary structured data is bad because XML is a markup language. I am not defending SAML more broadly or claiming that none of its mistakes were foreseeable, and particularly am not defending the idea of signing a DOM tree instead of a sequence of bytes. (Though the latter mistake is in principle orthogonal to XML vs. JSON; I confess to not really understanding why they're so correlated.)
XML is as complex as DER, and since there is a way to use XML in ASN.1 -called XER, or XML Encoding Rules-, XML is also as complex as ASN.1, and when you add FastInfoSet, even more still.
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 did not become more complex following 2002. DTD, Namespaces, Comments, processing instructions, CData, attribute vs. child dichotomy - all of these things exited from day 0.
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. Disagree. I think ASN.1 is not horribly complex, but I think BER/DER (which, yes, are in the ASN.1 family) and XML are.
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.
I’d point out that it’s possible for SAML to be acknowledged as okay or “good for its time,” even, and also be acknowledged as today amounting to a steaming pile of crap that ought to be avoided and phased out wherever possible. Even if all its flaws were just the bad luck of existing before other things were invented.
We can’t change the past anyway, but ‘considering SAML harmful’ today may be the most reasonable position to take.
Saml serializing to XML is not a problem at all, the problem is then including the signature within the XML, which Saml idiotically does. They could just as well have appended it to the xml with a separator. There's nothing about that that couldn't have been understood in 1995 or so.
I think ASN.1, specifically DER, actually would have been better because it avoids the canonicalization problems saml has, as well as the general XML problems like XXE.
IndieAuth is the way. Unfortunately, I don't think there's a lot of incentive for a site to implement it as a login option unless the site already has some reason to cater to IndieWeb lovers (including me). :^(
You can do that in principle. Most non enterprise tools don't support it because they don't merely want an IdP, they want an IdP doing anti-spam and reputation and outsourcing of account recovery and throttling of bulk user creation.
If anyone could attest to who they are at any time we could just have user/pass without email and call it a day.
The real problem is that they used eXtensible Markup Language but invented their own inner extensibility syntax on top of a language where this was already a core feature! It’s the first word in the name!
It’s like “using JSON” but actually encoding objects indirectly through your own made up object notation… that is structured.
Yeah, it never really got off the ground though because incentives weren’t aligned. Everyone wants you to sign up on their site for data hoarding reasons, not to use an identity from elsewhere.
> When authentication is just not a document or data stream that needs marked-up.
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
It's never ending.
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.
AIUI a “markup” language is for applying structured enhancement to a document containing effectively arbitrary contents. An unstructured source, but we need to add some structured components. Obviously today it has all reverted to a structured document object model, but one of the insights of HTML was, at least in the era of gopher and ftp, the system shouldn’t interfere with the data more than it needs to. If I write up a nicely formatted RFC text file, and I want to put it on the World Wide Web, I shouldn’t have to translate the whole thing to some other language. With HTML, I could, in a structured way that remains independent of the structure of my document, add enough bits to make it work with the World Wide Web. I could, in other words, take my already formatted and structured document, and mark it up with metadata.
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.
> 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.
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.
SAML sucks, but it still has a bunch of features for its specific narrow enterprise SSO use-case that OIDC lacks - most notably IdP-initiated flow. OIDC is a constellation of specs with inconsistent support across products, whereas the commonly-implemented subset of SAML is more-or-less stable in its mediocrity.
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.
OIDC doesn't support IDP initiated flows for a reason - they're vulnerable to a class of attacks known as Login CSRF. An attacker can trick a victim into submitting an IdP-initiated authentication response linked to the attacker's account/session into the victim's browser profile on the SP. Think - Eve tricks Bob into signing in to Eve's PayPal account instead of Bob's. Bob, none the wiser, links his bank account. Eve now has access to Bob's funds.
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.
SAML implementations can protect against this by turning IdP-initiated requests into an SP-initiated request. On the SP-initiated responses, there is an `InResponseTo` field that can be validated (or `RelayState` can be made to work).
The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.
OIDC spec has a limited third-party initiated flow[1] that redirects to the RP (equivalent to SP in SAML), which then starts a regular OIDC flow that is indistinguishable from an RP-initiated flow.
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.
I feel like there is an easy solution to login csrf with IdP initiated flows. The SP just gives a pop up saying - you are logging into X as user Y. Continue?
The has been proven again and again to not work. See for example HTTPS certificate warnings for which now there is a standard to ask browsers to not show a popup just saying "The server might not be the correct one. Continue?"
It's an easy solution, but it doesn't work at all.
Does Tailscale support SAML? If not: why would any other enterprise product need to? Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.
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.
> Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.
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
I think you're wrong about this, that basically every F500 with an access VPN setup has heard of Tailscale, and further, despite their penetration being much bigger than "tech companies in the valley", my point was that Tailscale is a modern business that exists to make (at this point) large amounts of money, and they're not doing SAML.
(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).
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.
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.
There are a lot of smaller providers that will eschew some features, require a fairly limited integration surface (was the case with a lot of things with Slack integration before Teams' COVID explosion, for instance) to keep their support and development costs down
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
One of the issues I've run into with Tailscale OIDC is that an email domain must be mapped to a single tailnet. So if my IdP has consultants or if my domain contains multiple businesses with different tailnets, I need to do some domain mapping in my IdP and train users to login with that special non-email address.
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.
When we started C1.ai - 2020 - as someone who worked previously at Okta - I made a decision to only implement OIDC. (see article for all of the reasons). We were worried in the first 2 years, that some big enterprise would force us to implement SAML.
But it turns out, all the major IDPs support OIDC now. It's a non-issue.
> Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.
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.
A fair criticism of the article is that it lists SAML's vulnerabilities but doesn't do the same comparison for OIDC. OIDC has its own problems too: JWT algorithm confusion, none algorithm attacks, missing audience checks, and bugs in JOSE libraries
SAML is even worse than the article describes, problems like needing to check what the signature actually signs. But I'm optimistic about the future, instead of relying on libraries that do a lot, such as general xml parsing, we can support a subset of SAML and only the dialects of the top ~10 providers. Extreme niche providers can be added ad-hoc and only if the deal size makes it worthwhile.
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.
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 XML, so the signature inside the document somewhere and signs some other part of the document by reference.
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.
Reminds me of a similar attack on PGP/MIME/HTML where you'd put <a href="http://evil.example/ in front of the PGP message.
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.
In a JWT this is simple, the signature checks the entire sig and data sections. In XML signatures it checks whatever it says it checks, a list of URIs, which may also be transformed.
So it is possible to have an XML signature that points to an element that does not include some important piece of data.
Yes it is, good catch. It's even linked under the text "especially at the time" in the post. I probably should have referenced it more prominently, but I thought it was a fun Easter egg under a more subtle link.
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.
I hope its referred to as "this is the article idiots who know nothing about modern php reference in a futile attempt to make it appear they know what they are talking about" as every time someone mentions that article it seems to be when they want to show everyone how daft they are.
I use a 20 year old web framework with an 18 year old build system and it was good the moment it came out. That's 66% of the lifespan of old PHP (its still around) and 181% of the lifespan of modern PHP.
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.
"You guys"? lol it's just a tool. I don't identify as "a PHP guy" for the same reason I don't identify as a "Rust guy". And labeling others like that is yet another red flag.
I use many languages. Some more than PHP. But that's besides the point.
I've not got a huge amount to appreciation for PHP but I'm not sure it makes sense in 2026 to refer back to an article which suggests Perl with Catalyst as an alternative to PHP with Symfony or Laravel.
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.
My goto when integrating SSO in a Java/JVM application via SAML, OAuth, JWT, and other authentication mechanisms is pac4j (https://github.com/pac4j/pac4j). It has integration to and demos for various web frameworks like Spring and Scala Play. It does a lot of the heavy lifting for integrating SSO into an application.
OIDC is based on Oauth2. The auth part of Oauth stands for authorization, not authentication which brings me to the problem I have with OIDC - namely OIDC is about granting external party access to your data. You can mitigate this a bit via using something like Okta, which just does not have this data, but lets say you don't have Okta and all you have is Google Workspace.
More generally, if you're creating anything involving security, avoid XML like the plague because mixing the control and data planes, which in turn contain executable content/instructions and data, together in a random jumble is the gift to hackers that just keeps on giving.
The issue is not that SAML is XML per se, but rather: (1) auth happens over public internet rather than server-to-server, allowing the user to MITM the message flow and (2) the various XML parsing libs in various languages do not have consistent behavior when it comes to looking up a node by name (i.e. if there are dupes) or finding a child node. MITM can exploit these divergences for auth bypasses, etc.
A SAML lib needs an extreme amount of XML sanitization, while still handling all the various “in-the-wild” XML format funkiness
“ Further, a committee of subcommittees having meetings is a recipe for “kitchen-sink” protocol design (e.g., waterfall methodology, big design up front, etc.).”
Re: canonicalization: design things to not need it, so don't bother with it. Relying parties need to received the blob of whatever (XML, JSON, DER, PB -- don't care or decode till the signature is validated), validate the signature over the exact blob you've received, then decode. This means you need the signing key's algorithm to be identifiable from its issuer and key ID metadata / URI. The header you'll need should only have the information you need to find (dereference) the issuer's signing public key. You'll never need to canonicalize anything this way.
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.
SAML is XML era legacy so mostly ugly but it's just the form of it. But all the security problems come from XMLDSIG which is just the worst signature scheme ever designed. So much complexity for so few to deliver. Just sign a bunch of bytes.
May be I am in a minority here, but there are areas where SAML sort of shines
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.
> 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
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.
JWT uses a famously misdesigned signature scheme. It’s kind of amazing that this article uses JWT as an example of being better than SAML — SAML really is awful!
The requirement for connected network topology is a non-starter for many SaaS products. I don't want my systems to be open to some backchannel communication from the SaaS providers service.
It's called design by committee. It's when you get everyone in a room and nobody can make a tradeoff because it would hurt someone else's pet use case, so you don't actually design anything at all, just build a framework within which a design can exist.
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.
Also, when you consider the age difference between the two, Wireguard is OpenVPN plus the learnt lessons.
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.
Before OpenVPN there was IP-in-IP encapsulation, which is as simple as a VPN can get (no encryption, but that hadn't been invented yet). Wireguard is basically IP-in-UDP plus encryption. You know what else is basically IP-in-UDP plus encryption? IPsec, and it really sucks, for the same reasons OpenVPN does.
> IP looked at that and said: fuck that noise - we send packets, if they don't arrive we send them again, job done.
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.
> 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.
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.
Eh, if you don't have SAML support, I can find a product that does. Not a problem. \o/
(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.)
Security is part of the story (beats keep track of different usernames+passwords for every tool), but convenience is also a major factor.
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.
This is only a reasonable stance at the very surface level.
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.
As a SaaS customer, interacting with SaaS vendors tends to entail:
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.
> 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.)
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!
The total cost to employee a Senior Software Engineer, and I mean a real one, not some kid with three years experience, including benefits, taxes, etc. easily gets up to 200K in a normal city at a non-FAANG job.
Im sorry if your UK salaries are much smaller, but I’m not P Diddy taking anyone’s piss out here m8!
Not denying that, but if its a full time job for that person to monitor the keycloak machines for a typical SaaS vendor then something's wrong at mill cobber (may have used that wrongly as not English)
> A potential customer making bad choices does not obligate a business to make bad choices for their business.
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.
Realistically, what modern IdP supports SAML but not OIDC though? To me, it seems like more of a case of 'I know and am comfortable with SAML, why learn something new?'.
Everything can stack onto everything else, sure. Most people's SAML IdPs are... synced from their LDAP. =) But in particular SAML provides an SSO experience where signing in once in the browser will allow you to go to various integrated sites and apps without signing in again. That flow is not dissimilar from OIDC but it is separate. So I can have 10 apps with SAML and 1 with OIDC, and the OIDC one is gonna be an odd duck.
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.
> 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 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.
If a company said "you must support DES," I would expect that their cybersecurity insurance provider would start asking them some questions, and if they became indignant that no one would do so, I would expect them to be publicly mocked.
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.
Honestly, it's an addressable market versus development cost question... How many clients will you lose if you support OIDC but not SAML? Does the delta justify carrying a SAML implementation? If so, do it. But the post is still correct that SAML is a fractal of bad design either way. And it's good to say this openly, and to run this calculus each time you are considering a new SAML implementation.
Oh boy. There were (and are) hordes of enterprises requiring us to support SAML and were quite amazed to know Entra and all big auth providers perfectly support OIDC.
SAML is bad, but OAuth and OIDC are showing major cracks with identity and agents. Go to any major company right now and ask them how they are dealing with authenticating agents/what an agent identity even is.
The XSW part of the article was new to me though and kinda shocking
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.
OAuth2 is about a billion times better than SAML. At least you have a decent chance of doing it securely if you follow the spec vs about zero chance with saml.
I kinda disagree. Authentication is at OAuths core. You still need to authenticate to obtain a token and in more complex setups you don’t use it for authorization at all because tokens are stale immediately after issuing them. It’s why things like Zanzibar and OPA have been made.
It’s really not. OAuth makes zero assumptions about how you login - granted, the client credentials flow is a form of authentication if you will, but for the user perspective, OAuth starts when you’re signed in. That’s also why you can easily combine it with all kinds of authentication providers.
> OAuth makes zero assumptions about how you login
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.
My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also:
- 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.
I saw multiple implementations that looked for a signature, verified it, then just trusted the document as a whole rather than only the part that was signed. So as long as you had any signed SAML doc, you could provide an attention of your choosing and just bundle the signed one somewhere arbitrary inside of it.
It really probably is the worst security specification ever written.
It’s also enormous, I assume from the attempt to have nominally composable parts that could be reused for other flows.
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.
It is truly surprising how large the specs for each of these ecosystems are: PKI, Kerberos, TLS, OAuth, SAML, etc. They are gargantuan, especially when you include essential dependencies like DER codecs and ASN.1 compilers (PKI, Kerberos) or XML (SAML).
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
C. A. R. Hoare
The problem with this is the assumption that there's a simpler way to do all of this, and if only we could stop looking for large and complex solutions we could just land on the simple ones.
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.
The thing is that they don't have to be that big at all, you could probably specify enough of PKI and TLS and SSH to cover most uses cases in, I dunno, 30-40 pages. However the standards bodies that produced them, termed "working groups", are more like standing committees that will (a) standardize any random idea that any member brings along and (b) are worse than the energizer bunny, they just keep going and going and going and going. Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS). You can't stop these standards mills, they'll just keep grinding out more stuff that no-one ever asked for, for all of eternity.
It sure sounds like it should be like this, but when you actually try you end up with not this. TLS is huge! Yes, but SSL 2.0 was smaller, and buggy as hell, so it had to evolve, and after 30+ years it became the monster that it is today.
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.
> Even ones that have been forcibly shut down like PKIX just keep going in other forms (LAMPS).
Was the IETF PKIX WG "forcibly" shut down, or it merely concluded, with new WGs popping up to do similar things when needs arose?
Well, no-one held a gun to their head but there was a general "enough, already", aided by the fact that several of the main characters were retiring which helped wind it up. And then they just kept going as before under a new name and with an influx of new people who were unaware of how the original mess was made and why.
IETF WGs conclude, and then new ones get created to take the mantle when needed. Happens all the time.
So if a WG is wound up and then continues under another name with mostly the same people doing the same things the original WG did it's not really wound up, is it? It's just changing the sign over the door with business continuing as usual.
I sense anger, possibly born of misunderstanding.
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.
The root problem with SAML is there’s a million and one permutations to do the same thing.
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.
That's because its built in part on XMLDSig, a genius idea to sign active content that can redefine its own semantics as it's being signed/verified. It's a triumph of ideology over common sense.
I think I got to the canonicalization part of the relevant spec and decided that life was too short...
NB I can absolutely see why canonicalization is required... just that it was the bit where I lost interest
The first book that came out on XMLDSig, "Secure XML: The New Syntax for Signatures and Encryption", written by the chair of the working group, spent over half of its 500 pages wrestling with canonicalization, and even then it read more as a 250-page problem statement than a solution.
And that was before you got into deliberately malicious content that actively subverts the signature process.
Any specification that comes out of OASIS is almost guaranteed to be ridiculously complicated and mostly impossible to implement securely.
Which, given the output of the IPsec and PKIX working groups, is saying something.
I say this a lot, but: there was a conspiracy theory that NSA had infiltrated the IETF during the original IPSEC standardization effort and injected the "TLS BEAST" CBC IV chaining vulnerability, which is funny because we actually know exactly how that happened (professional academic cryptographers took out a petition to get the bug fixed and were shouted down by standards body gadflies who literally rejected the premise that there was such a thing as a professional academic cryptographer). This is really easy to see once you've done an engagement on DSIG security! Standards bodies are more than capable of fucking things up entirely on their own. If anything, NSA would risk making protocols stronger by intervening in their natural processes.
NSA has their own stripped down and opinionated profiles of IPsec that they mandate for applications they really care about.
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.
"Never attribute to malice what is adequately explained by stupidity". Or, in this case, design-by-committee by a bunch of people who haven't written ten lines of code in as many years. There have been several other cases where absolute no-brainer fixes, like one or two lines of code changed, to long-standing security problems, were filibustered, or blocked by WG chairs, for no explainable reason, and they can't all have been paid by the NSA to do that.
The people running these WGs are mostly professional committee members who get paid by their employers to fly around the world to attend meetings.
They don’t build products, they don’t operate networks, and they don’t talk to customers.
Yes, absolutely. And it's self-selection for mediocrity, people who are useless at any other task and prepared to argue endlessly over pointless technicalities that no-one apart from other professional meeting-goers care about are perfect for dumping onto standards committees.
Thanks now I can't sleep and I need to send our pentesters who just finished pentesting seventh security patch to our SAML another email.
This is a pretty common implementation error. You can just add your own assertion that overwrites any claims in the signed assertion (such as username) and use it to escalate privileges or take over any account that you like.
I maintain a popular Saml library for NET (aspnetsaml). And yep, I made that rookie mistake too
Didn’t JWT have a similar thing, where you could specify the algorithm to use and that included “null”?
JWT has two out of the three issues mentioned above:
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.
Yeah I wanted to use alg none for some unit tests once (it was easier than setting up the next lowest tier security option) but whichever Java library I was using had completely disabled it. I could see it had been supported at some point but it had been updated so that it couldn't be enabled at all.
Yes, that’s a good thing. That alg:none might be easy in tests is not a good reason for a weak mode in the real code and spec.
Been there, done that, wrote the stub/mock and ended up with the better test. :)
Wasn’t it like a month ago when Sharepoint still accepted alg:none? I guess that proves they’re not using Java :)
[dead]
Yes. JWT also had a bug where some implementations would use the pubkey as an hmac password if you switched the algorithm which is similarly bad.
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.
Yeah, the standard should have just specified like a sha256 HMAC, when that becomes broken in 20 years we can just do a JWT2 (or invent some new successor standard)
given that md5-hmac isn't even broken despite md5 being broken, it seems unlikely sha256-hmac will fall in 20 years.
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.
https://www.howmanydayssinceajwtalgnonevuln.com/
Yes, but you shouldn't be taking instruction on how to verify the security of a JWT from the JWT itself in the first place. Don't follow an attacker's security steps.
Sites don't get hacked because it's easier to social engineer a persons password.
It’s such a product of “Ooh! Markup languages! What can we use a markup language to solve!” When authentication is just not a document or data stream that needs marked-up.
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
OpenID Connect actually has all the machinery needed to support federated login as part of its dynamic discovery and dynamic registration specifications. The issue is that absolutely no one uses them or implements them.
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.
As someone with a vested interest/being/been many of the parties you mention... Do you think support for "federated login via OIDC" would _not_ fall under the SSO tax?
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.
With dynamic client registration, I could host my own IdP server at home, or with a provider of my choice, and it would just work everywhere without any coordination work for anyone, manual signups to be assigned a client id/secret, etc. The entire point is that you won't let me do that because you want to charge extra for better, simpler, cheaper security for everyone. That is the SSO tax.
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.
GP was probably thinking of Azure AD / Entra as the "SSO tax".
https://sso.tax/
Thanks!
OpenID started its life as an attempt at a federated login standard.
From vague memory, the other stuff in OpenID Connect was layered over the original OpenID identity verification part.
There is nothing left from the OpenID 1.0 and 2.0 protocol in OpenID Connect, except for the core features (identity federation, identity information encoding and updates).
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.
OpenID Connect is OAuth2 extended to cover a similar feature set as OpenID.
Yeah I’m so old, I remember when LiveJournal (probably when bradfitz was still involved) were among the first to support original OpenID.
Why haven't (we?) these federation features been used?
Federation sounds like decentralization to me. Decentralized is like a dirty word when you’re in the business of either selling SaaS or pushing private citizens to go all in on the GOOG/AAPL/MSFT ecosystems. And everyone with any influence over what gets adopted and used, is in those categories.
They are being used. Workload Identity Federation is often used to assign oidc identities to workloads and the Client ID Metadata Document (basically dynamic client registration) is used in protocols such as MCP and atproto
As the article points out, it's not really fair to criticize SAML for not using JSON, given that JSON barely existed at the time.
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.
I don't understand this definition of "fair". Things are either good or they're not. Signed XML is not good. That's a fair claim, even if the designers of XMLDSIG didn't know as much as we do.
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.
My comment was aimed at the particular critique I was replying to, namely, that using XML for ordinary structured data is bad because XML is a markup language. I am not defending SAML more broadly or claiming that none of its mistakes were foreseeable, and particularly am not defending the idea of signing a DOM tree instead of a sequence of bytes. (Though the latter mistake is in principle orthogonal to XML vs. JSON; I confess to not really understanding why they're so correlated.)
OK, totally fair: I'm hair-trigger about attempts to rehabilitate DSIG and SAML, but I have basically no opinions about XML itself. Sorry!
XML is as complex as DER, and since there is a way to use XML in ASN.1 -called XER, or XML Encoding Rules-, XML is also as complex as ASN.1, and when you add FastInfoSet, even more still.
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 did not become more complex following 2002. DTD, Namespaces, Comments, processing instructions, CData, attribute vs. child dichotomy - all of these things exited from day 0.
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/
1. Disagree. I think ASN.1 is not horribly complex, but I think BER/DER (which, yes, are in the ASN.1 family) and XML are.
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.
I’d point out that it’s possible for SAML to be acknowledged as okay or “good for its time,” even, and also be acknowledged as today amounting to a steaming pile of crap that ought to be avoided and phased out wherever possible. Even if all its flaws were just the bad luck of existing before other things were invented.
We can’t change the past anyway, but ‘considering SAML harmful’ today may be the most reasonable position to take.
Saml serializing to XML is not a problem at all, the problem is then including the signature within the XML, which Saml idiotically does. They could just as well have appended it to the xml with a separator. There's nothing about that that couldn't have been understood in 1995 or so.
I think ASN.1, specifically DER, actually would have been better because it avoids the canonicalization problems saml has, as well as the general XML problems like XXE.
> 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
IndieAuth exists, it's just not widely supported.
IndieAuth is the way. Unfortunately, I don't think there's a lot of incentive for a site to implement it as a login option unless the site already has some reason to cater to IndieWeb lovers (including me). :^(
You can do that in principle. Most non enterprise tools don't support it because they don't merely want an IdP, they want an IdP doing anti-spam and reputation and outsourcing of account recovery and throttling of bulk user creation.
If anyone could attest to who they are at any time we could just have user/pass without email and call it a day.
The real problem is that they used eXtensible Markup Language but invented their own inner extensibility syntax on top of a language where this was already a core feature! It’s the first word in the name!
It’s like “using JSON” but actually encoding objects indirectly through your own made up object notation… that is structured.
That's what the original OpenID (from back in the LiveJournal days) was supposed to be right?
"Host your own identity"
Yeah, it never really got off the ground though because incentives weren’t aligned. Everyone wants you to sign up on their site for data hoarding reasons, not to use an identity from elsewhere.
When I first learned about OIDC, I thought.. I can log in to Google and Apple using MY identity? Sweet.
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.)
> When authentication is just not a document or data stream that needs marked-up.
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:
It's never ending.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.
AIUI a “markup” language is for applying structured enhancement to a document containing effectively arbitrary contents. An unstructured source, but we need to add some structured components. Obviously today it has all reverted to a structured document object model, but one of the insights of HTML was, at least in the era of gopher and ftp, the system shouldn’t interfere with the data more than it needs to. If I write up a nicely formatted RFC text file, and I want to put it on the World Wide Web, I shouldn’t have to translate the whole thing to some other language. With HTML, I could, in a structured way that remains independent of the structure of my document, add enough bits to make it work with the World Wide Web. I could, in other words, take my already formatted and structured document, and mark it up with metadata.
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.
> 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.
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.
> What we are missing is a provider-independent way to do this.
A new IndieAuth-like pattern is emerging for how to do this, based on the combination of OAuth, FedCM and DIDs.
https://notes.erlend.sh/3mpodece2qk2g
SAML sucks, but it still has a bunch of features for its specific narrow enterprise SSO use-case that OIDC lacks - most notably IdP-initiated flow. OIDC is a constellation of specs with inconsistent support across products, whereas the commonly-implemented subset of SAML is more-or-less stable in its mediocrity.
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.
OIDC doesn't support IDP initiated flows for a reason - they're vulnerable to a class of attacks known as Login CSRF. An attacker can trick a victim into submitting an IdP-initiated authentication response linked to the attacker's account/session into the victim's browser profile on the SP. Think - Eve tricks Bob into signing in to Eve's PayPal account instead of Bob's. Bob, none the wiser, links his bank account. Eve now has access to Bob's funds.
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.
SAML implementations can protect against this by turning IdP-initiated requests into an SP-initiated request. On the SP-initiated responses, there is an `InResponseTo` field that can be validated (or `RelayState` can be made to work).
The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.
OIDC spec has a limited third-party initiated flow[1] that redirects to the RP (equivalent to SP in SAML), which then starts a regular OIDC flow that is indistinguishable from an RP-initiated flow.
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...
I feel like there is an easy solution to login csrf with IdP initiated flows. The SP just gives a pop up saying - you are logging into X as user Y. Continue?
The has been proven again and again to not work. See for example HTTPS certificate warnings for which now there is a standard to ask browsers to not show a popup just saying "The server might not be the correct one. Continue?"
It's an easy solution, but it doesn't work at all.
I don't really think that is comparable.
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.
What is prventing OIDC-based IdP from initiating login? You just need to know the login URI:
https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...
Does Tailscale support SAML? If not: why would any other enterprise product need to? Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.
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.
> Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.
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
I think you're wrong about this, that basically every F500 with an access VPN setup has heard of Tailscale, and further, despite their penetration being much bigger than "tech companies in the valley", my point was that Tailscale is a modern business that exists to make (at this point) large amounts of money, and they're not doing SAML.
(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).
And I think you're wrong about this too.
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.
Agreed.
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.
There are a lot of smaller providers that will eschew some features, require a fairly limited integration surface (was the case with a lot of things with Slack integration before Teams' COVID explosion, for instance) to keep their support and development costs down
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
One of the issues I've run into with Tailscale OIDC is that an email domain must be mapped to a single tailnet. So if my IdP has consultants or if my domain contains multiple businesses with different tailnets, I need to do some domain mapping in my IdP and train users to login with that special non-email address.
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.
When we started C1.ai - 2020 - as someone who worked previously at Okta - I made a decision to only implement OIDC. (see article for all of the reasons). We were worried in the first 2 years, that some big enterprise would force us to implement SAML.
But it turns out, all the major IDPs support OIDC now. It's a non-issue.
You can use Keycloak as a SAML/OIDC -adapter.
> Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.
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.
Eh, many of us do what I think you mean by "IdP-initiated flow"s with JWT. It's not OAuth exactly, but it's a thing.
A fair criticism of the article is that it lists SAML's vulnerabilities but doesn't do the same comparison for OIDC. OIDC has its own problems too: JWT algorithm confusion, none algorithm attacks, missing audience checks, and bugs in JOSE libraries
SAML has audience checks and selectable algorithms. I don't like JWT, but it's no XMLDSIG.
SAML is even worse than the article describes, problems like needing to check what the signature actually signs. But I'm optimistic about the future, instead of relying on libraries that do a lot, such as general xml parsing, we can support a subset of SAML and only the dialects of the top ~10 providers. Extreme niche providers can be added ad-hoc and only if the deal size makes it worthwhile.
What's an example of a well-tested and well-written library that only supports a (good) subset of SAML?
This one? https://developers.onelogin.com/docs/saml/
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.
https://github.com/SAML-Toolkits/java-saml last updated 2+ years ago!
> … needing to check what the signature actually signs.
I mean … how else would you check a signature? You have to have the data to validate the signature.
Normally you sign the whole dicument.
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.
And this doesn't even get into "which normalization approach!" or "what gets signed (or not)!"
It's an absolute dumpster fire.
It’s XML, so the signature inside the document somewhere and signs some other part of the document by reference.
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.
Reminds me of a similar attack on PGP/MIME/HTML where you'd put <a href="http://evil.example/ in front of the PGP message.
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.
In a JWT this is simple, the signature checks the entire sig and data sections. In XML signatures it checks whatever it says it checks, a list of URIs, which may also be transformed.
So it is possible to have an XML signature that points to an element that does not include some important piece of data.
Or maybe it does include the important info at sign time, but the attacker adds additional info that confuses the program parsing the document.
I have to know. Is this a play on the ever-so-popular https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Yes it is, good catch. It's even linked under the text "especially at the time" in the post. I probably should have referenced it more prominently, but I thought it was a fun Easter egg under a more subtle link.
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
Because you asked that, the article is now called "SAML Considered Harmful"
This is one of my favorite articles. I refer back to it whenever the subject of PHP comes up.
I hope its referred to as "this is the article idiots who know nothing about modern php reference in a futile attempt to make it appear they know what they are talking about" as every time someone mentions that article it seems to be when they want to show everyone how daft they are.
There's a lot of hype-chasing morons who diss old languages without knowing the first thing about them.
You'd be shocked at the number of developers that believe C has no types.
Yeah it's an instant red flag when someone links that outdated article.
Signals their ease to spit out incorrect information with confidence. That has no place in engineering.
I use a 20 year old web framework with an 18 year old build system and it was good the moment it came out. That's 66% of the lifespan of old PHP (its still around) and 181% of the lifespan of modern PHP.
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.
"You guys"? lol it's just a tool. I don't identify as "a PHP guy" for the same reason I don't identify as a "Rust guy". And labeling others like that is yet another red flag.
I use many languages. Some more than PHP. But that's besides the point.
I just thought it was funny. But ok.
I've not got a huge amount to appreciation for PHP but I'm not sure it makes sense in 2026 to refer back to an article which suggests Perl with Catalyst as an alternative to PHP with Symfony or Laravel.
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.
Have you kept up with the improvements in the latest PHP versions?
I have not. As above, I just find the article humorous.
Nobody calls me McGregor the Bridgebuilder.
ODIC cannot operate with a private-network IdP.
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.
> ODIC cannot operate with a private-network IdP
Why not? The flow can be entirely client side. OpenID discovery and PAR is optional and those would require direct connections
Yes, you could develop a client-side (JavaScript) application to do this.
SAML does not require JavaScript to do that.
>It’s time to deprecate it and move on to modern alternatives like OpenID Connect (OIDC)
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
My goto when integrating SSO in a Java/JVM application via SAML, OAuth, JWT, and other authentication mechanisms is pac4j (https://github.com/pac4j/pac4j). It has integration to and demos for various web frameworks like Spring and Scala Play. It does a lot of the heavy lifting for integrating SSO into an application.
OIDC is based on Oauth2. The auth part of Oauth stands for authorization, not authentication which brings me to the problem I have with OIDC - namely OIDC is about granting external party access to your data. You can mitigate this a bit via using something like Okta, which just does not have this data, but lets say you don't have Okta and all you have is Google Workspace.
"... it’s not the committee’s fault. XML is what they had at the time, and it’s what people used. JSON was “discovered” in 2001 ..."
The committee had, at the very least, ASN.1. Not text, but any digital signature scheme has to be machine readable, not human readable.
More generally, if you're creating anything involving security, avoid XML like the plague because mixing the control and data planes, which in turn contain executable content/instructions and data, together in a random jumble is the gift to hackers that just keeps on giving.
The issue is not that SAML is XML per se, but rather: (1) auth happens over public internet rather than server-to-server, allowing the user to MITM the message flow and (2) the various XML parsing libs in various languages do not have consistent behavior when it comes to looking up a node by name (i.e. if there are dupes) or finding a child node. MITM can exploit these divergences for auth bypasses, etc.
A SAML lib needs an extreme amount of XML sanitization, while still handling all the various “in-the-wild” XML format funkiness
“ Further, a committee of subcommittees having meetings is a recipe for “kitchen-sink” protocol design (e.g., waterfall methodology, big design up front, etc.).”
- personally, I like having a kitchen sink
Re: canonicalization: design things to not need it, so don't bother with it. Relying parties need to received the blob of whatever (XML, JSON, DER, PB -- don't care or decode till the signature is validated), validate the signature over the exact blob you've received, then decode. This means you need the signing key's algorithm to be identifiable from its issuer and key ID metadata / URI. The header you'll need should only have the information you need to find (dereference) the issuer's signing public key. You'll never need to canonicalize anything this way.
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.
[flagged]
SAML is XML era legacy so mostly ugly but it's just the form of it. But all the security problems come from XMLDSIG which is just the worst signature scheme ever designed. So much complexity for so few to deliver. Just sign a bunch of bytes.
Right, so is there a PHP SAML module that perfectly fits like a fractal hand in a fractal glove?
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
May be I am in a minority here, but there are areas where SAML sort of shines
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.
> 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
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.
There’s such a thing as a blunt, unwieldy dangerous tool. It gets the job done. Also people using it are torturing themselves.
JWT uses a famously misdesigned signature scheme. It’s kind of amazing that this article uses JWT as an example of being better than SAML — SAML really is awful!
My shitty overcomplicated design is better than your shitty overcomplicated design!
Waiting for the "OIDC: Time for Authentication to Take a Xanny" article
The requirement for connected network topology is a non-starter for many SaaS products. I don't want my systems to be open to some backchannel communication from the SaaS providers service.
That seems like a bit of an arbitrary line to draw, no? Would you say the same about webhooks?
Ah, SAML. The protocol where every vendor implements it slightly differently, ensuring endless configuration headaches.
The deeper you dig into SAML, the more arbitrary complexity you uncover. Each layer reveals another baffling design choice.
Just shipped another SAML integration; pretty sure I lost a few years off my life. The XML signature bits always get me.
It's called design by committee. It's when you get everyone in a room and nobody can make a tradeoff because it would hurt someone else's pet use case, so you don't actually design anything at all, just build a framework within which a design can exist.
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.
Also, when you consider the age difference between the two, Wireguard is OpenVPN plus the learnt lessons.
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.
Before OpenVPN there was IP-in-IP encapsulation, which is as simple as a VPN can get (no encryption, but that hadn't been invented yet). Wireguard is basically IP-in-UDP plus encryption. You know what else is basically IP-in-UDP plus encryption? IPsec, and it really sucks, for the same reasons OpenVPN does.
By "encryption, but that hadn't been invented yet" you mean like, specifically encrypted network streams, right?
> IP looked at that and said: fuck that noise - we send packets, if they don't arrive we send them again, job done.
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.
> 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.
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.
[dead]
Eh, if you don't have SAML support, I can find a product that does. Not a problem. \o/
(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.)
That mindset is indicative of security theatre to me. But as security theatre is common in entrprise IT that does not surprise me.
Security is part of the story (beats keep track of different usernames+passwords for every tool), but convenience is also a major factor.
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.
> I'm an IT consultant working for a private company
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.
This is only a reasonable stance at the very surface level.
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.
It seems fair to me.
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.
As a SaaS customer, interacting with SaaS vendors tends to entail:
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.
> 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.)
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!
You do know about Keycloak right?
You do know that the “Total Cost of Ownership” is non-zero?
I do but $200K per year actual cost is taking the piss.
The total cost to employee a Senior Software Engineer, and I mean a real one, not some kid with three years experience, including benefits, taxes, etc. easily gets up to 200K in a normal city at a non-FAANG job.
Im sorry if your UK salaries are much smaller, but I’m not P Diddy taking anyone’s piss out here m8!
Not denying that, but if its a full time job for that person to monitor the keycloak machines for a typical SaaS vendor then something's wrong at mill cobber (may have used that wrongly as not English)
> A potential customer making bad choices does not obligate a business to make bad choices for their business.
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.
Realistically, what modern IdP supports SAML but not OIDC though? To me, it seems like more of a case of 'I know and am comfortable with SAML, why learn something new?'.
Everything can stack onto everything else, sure. Most people's SAML IdPs are... synced from their LDAP. =) But in particular SAML provides an SSO experience where signing in once in the browser will allow you to go to various integrated sites and apps without signing in again. That flow is not dissimilar from OIDC but it is separate. So I can have 10 apps with SAML and 1 with OIDC, and the OIDC one is gonna be an odd duck.
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.
> 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 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
If a company said "you must support DES," I would expect that their cybersecurity insurance provider would start asking them some questions, and if they became indignant that no one would do so, I would expect them to be publicly mocked.
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.
It's outdated in the way that the author doesn't like it, but SAML will probably outlive OIDC.
Honestly, it's an addressable market versus development cost question... How many clients will you lose if you support OIDC but not SAML? Does the delta justify carrying a SAML implementation? If so, do it. But the post is still correct that SAML is a fractal of bad design either way. And it's good to say this openly, and to run this calculus each time you are considering a new SAML implementation.
We took that exact stance, and it’s largely been a success. Most people asking for SAML can actually do OIDC and are happy to do so.
It's a matter of perspective yes.
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.
Oh boy. There were (and are) hordes of enterprises requiring us to support SAML and were quite amazed to know Entra and all big auth providers perfectly support OIDC.
You use Entra. Entra can do jwt’s.
Saml is just not reasonable in our modern security environment.
Entra is just allowing the Chinese government in your environment. Why bother with authentication at all?
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.)
SAML is bad, but OAuth and OIDC are showing major cracks with identity and agents. Go to any major company right now and ask them how they are dealing with authenticating agents/what an agent identity even is.
The XSW part of the article was new to me though and kinda shocking
It's probably for the better that they're having trouble with it, if trouble actually means increased workload.
If my security system is showing friction when there's a wave of agentic slop, I'd say that's a win.
RFC8628 has been out for eight years, OAuth isn't standing in the way of bots anymore.
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.
Implementing all the main authentication mechanisms is hell.
Oauth2 is utter utter shite as well.
OAuth2 is fine, I mean:
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.
OAuth2 is about a billion times better than SAML. At least you have a decent chance of doing it securely if you follow the spec vs about zero chance with saml.
Why are you using an authorization protocol for authentication? Try OIDC.
OIDC is a layer on top of OAuth...
Yes. But it’s authentication, whereas OAuth is authorization.
I kinda disagree. Authentication is at OAuths core. You still need to authenticate to obtain a token and in more complex setups you don’t use it for authorization at all because tokens are stale immediately after issuing them. It’s why things like Zanzibar and OPA have been made.
It’s really not. OAuth makes zero assumptions about how you login - granted, the client credentials flow is a form of authentication if you will, but for the user perspective, OAuth starts when you’re signed in. That’s also why you can easily combine it with all kinds of authentication providers.
> OAuth makes zero assumptions about how you login
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.
PHP vibes all over again
[flagged]