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
tptacek 28 minutes ago [-]
SAML has audience checks and selectable algorithms. I don't like JWT, but it's no XMLDSIG.
bawolff 2 hours ago [-]
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.
stouset 2 hours ago [-]
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.
tptacek 2 hours ago [-]
It really probably is the worst security specification ever written.
stouset 1 hours ago [-]
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.
koolba 1 hours ago [-]
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.
cameronh90 55 minutes ago [-]
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.
tptacek 29 minutes ago [-]
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.
jmbwell 3 hours ago [-]
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
blm126 2 hours ago [-]
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.
degamad 1 hours ago [-]
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.
CodesInChaos 30 minutes ago [-]
OpenID Connect is OAuth2 extended to cover a similar feature set as OpenID.
ameliaquining 1 hours ago [-]
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.
tptacek 26 minutes ago [-]
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.
matrss 2 hours ago [-]
> 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.
jiggawatts 1 hours ago [-]
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.
martijnvds 3 hours ago [-]
That's what the original OpenID (from back in the LiveJournal days) was supposed to be right?
"Host your own identity"
unethical_ban 53 minutes ago [-]
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.
fire7000 13 minutes ago [-]
“ 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
arpinum 3 hours ago [-]
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.
bklyn11201 38 minutes ago [-]
What's an example of a well-tested and well-written library that only supports a (good) subset of SAML?
jagged-chisel 3 hours 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.
stouset 1 hours ago [-]
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.
bawolff 2 hours ago [-]
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.
owenmarshall 2 hours ago [-]
And this doesn't even get into "which normalization approach!" or "what gets signed (or not)!"
It's an absolute dumpster fire.
arpinum 2 hours ago [-]
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.
bawolff 2 hours ago [-]
Or maybe it does include the important info at sign time, but the attacker adds additional info that confuses the program parsing the document.
sandeepkd 3 hours ago [-]
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.
paulddraper 9 minutes ago [-]
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.
Because you asked that, the article is now called "SAML Considered Harmful"
all2 2 hours ago [-]
This is one of my favorite articles. I refer back to it whenever the subject of PHP comes up.
esskay 1 hours ago [-]
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.
1 hours ago [-]
bbg2401 1 hours ago [-]
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.
g8oz 1 hours ago [-]
Have you kept up with the improvements in the latest PHP versions?
pocksuppet 3 hours ago [-]
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.
9dev 40 seconds ago [-]
> 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.
bayindirh 3 hours ago [-]
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.
pocksuppet 3 hours ago [-]
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.
LoganDark 3 hours ago [-]
By "encryption, but that hadn't been invented yet" you mean like, specifically encrypted network streams, right?
miguelspizza 3 hours ago [-]
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
jeroenhd 3 hours ago [-]
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.
TZubiri 3 hours ago [-]
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.
Hizonner 24 minutes ago [-]
My shitty overcomplicated design is better than your shitty overcomplicated design!
TZubiri 3 hours ago [-]
>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
xyst 3 hours ago [-]
Waiting for the "OIDC: Time for Authentication to Take a Xanny" article
stuaxo 3 hours ago [-]
Implementing all the main authentication mechanisms is hell.
Oauth2 is utter utter shite as well.
skrtskrt 2 hours ago [-]
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.
bawolff 2 hours ago [-]
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.
7bit 3 hours ago [-]
Why are you using an authorization protocol for authentication? Try OIDC.
vips7L 2 hours ago [-]
OIDC is a layer on top of OAuth...
cratermoon 4 hours ago [-]
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.
foltik 2 hours ago [-]
That seems like a bit of an arbitrary line to draw, no? Would you say the same about webhooks?
3 hours ago [-]
ocdtrekkie 4 hours ago [-]
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.)
jeltz 4 hours ago [-]
That mindset is indicative of security theatre to me. But as security theatre is common in entrprise IT that does not surprise me.
jeroenhd 3 hours ago [-]
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.
foltik 2 hours ago [-]
> 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.
eximius 4 hours ago [-]
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.
beachy 4 hours ago [-]
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.
ocdtrekkie 4 hours ago [-]
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.
antonymoose 3 hours ago [-]
> 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!
beachy 3 hours ago [-]
You do know about Keycloak right?
antonymoose 2 hours ago [-]
You do know that the “Total Cost of Ownership” is non-zero?
beachy 1 hours ago [-]
I do but $200K per year actual cost is taking the piss.
bigstrat2003 4 hours ago [-]
> 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.
iamjake648 4 hours ago [-]
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?'.
clhodapp 4 hours ago [-]
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.
badgersnake 3 hours ago [-]
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.
TZubiri 3 hours ago [-]
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.
tomjen3 4 hours ago [-]
You use Entra. Entra can do jwt’s.
Saml is just not reasonable in our modern security environment.
ocdtrekkie 4 hours ago [-]
Entra is just allowing the Chinese government in your environment. Why bother with authentication at all?
- check it against an hmac using a password specified in the attacker controlled document.
- check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)
I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.
It’s three entire specs bundled as one. One for the XML components, another for the documents you build from them, and another for the authentication flows built on top.
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.
OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.
I don't believe it's plausible for any non-specialist firm to implement SAML without grave vulnerabilities. I'm not sure I've ever seen it done well. It's been a minute since I've looked (I haven't consulted in several years, but, more importantly: most firms avoid SAML now), but I'm guessing that assertion still holds.
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
Smaller tech companies don't want federated login to happen. They are, as a rule, far to happy to rely on the SSO tax to up-sell enterprise customers. The major authentication companies don't want federated login to happy because it invites more competitors and threatens their absurd margins.
Until someone manages to solve the business side, no amount of improved technology will change a thing. I'm pretty sure the few small interoperability gaps OpenID Connect has could be corrected in a matter of months if the stakeholders actually cared.
From vague memory, the other stuff in OpenID Connect was layered over the original OpenID identity verification part.
If you needed a serialized representation of structured data, I think it made engineering sense to use XML even if it was more featureful than you needed. The alternatives were ASN.1 or rolling your own format from scratch. It's not at all obvious that those are better.
(You could argue in favor of rolling your own format on the grounds that it wouldn't be vulnerable to XML-specific security problems, but I don't think those problems were fully appreciated at the time. If they had been, probably people would have come up with some kind of quasi-standardizable secure XML variant that just disables the specific features that cause those problems.)
I agree that XML (even without the security-relevant misfeatures) is worse than JSON or other non-markup-language serialization formats for the majority of use cases that don't need a markup language, but this is not a big problem, it's basically just syntax.
The DSIG problems are wildly worse than syntax! There's a document object model to contend with, along with invariably-fatal parser differential bugs, and that's before you confront the one global C implementation that almost every DSIG implementation ends up relying on.
IndieAuth exists, it's just not widely supported.
It’s like “using JSON” but actually encoding objects indirectly through your own made up object notation… that is structured.
"Host your own identity"
If anyone could attest to who they are at any time we could just have user/pass without email and call it a day.
- personally, I like having a kitchen sink
I mean … how else would you check a signature? You have to have the data to validate the signature.
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.
In SAML you sign a (potentially attacker controlled) subset after normalization. So a lot of saml bugs come down to the attacker adding things that aren't covered by the signature. Sometimes this means appending or prepending stuff, but my favourite is adding comments which can alter the interpretation of the xml document (as it splits text nodes) but doesn't alter the signature.
It's an absolute dumpster fire.
So it is possible to have an XML signature that points to an element that does not include some important piece of data.
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.
SAML can.
In general, SAML is complicated because (1) auth is complicated (2) XML is complicated (3) canonicalization/signatures are complicated.
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.
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.
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.
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.
The XSW part of the article was new to me though and kinda shocking
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.
If my security system is showing friction when there's a wave of agentic slop, I'd say that's a win.
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
Oauth2 is utter utter shite as well.
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.
(Or to be more clear, it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with. You either work with what we use or you are not viable as a product for our need. It's kinda simple. I would expect someone whose authentication was OIDC-based to be similarly dismissive if you told them you only would do SAML.)
Pretty much everything supports SAML. If you decide not to support one of the standard protocols for SSO, you'll lose out on customers. Your tool has to bring in a lot of benefit (and have no competition) to warrant upending a company's entire auth system for.
Makes sense for GP locally, I guess, but globally we’re all worse off when nobody is motivated to break free from the path of least resistance.
1. "You either work with what we use" - so whatever organization you represent isn't capable of evaluating and shifting to more secure technologies?
2. "it is mostly unacceptable for an enterprise product to have opinionated decisions about what authentication it works with" - you think companies that care about security should not care about integrating with flawed protocols?
A potential customer making bad choices does not obligate a business to make bad choices for their business.
As a SaaS vendor, interacting with our customers about SAML usually involves:
a) them knowing what they want because they already have SAML-based SSO and it works for them; and
b) our contact on their side being some unfortunate support dude who got given SAML as their subject area for whatever reason, and who knows very little about it, and who is 4 levels in the org away from anyone empowered to make decisions as significant as moving away from SAML.
1. Finding out a company wants several grand to flip the "allow SAML" switch on the tenant config, and a few thousand a year in additional licensing to leave it on. (I had a vendor both tell me it "takes five minutes" to get it set up, and then quote me $4,800 to "implement" it.)
2. Having to yell at the SaaS vendor for routing the identity connection between two or three other identity providers in different various clouds because, you know "modern stuff". (A vendor I am working with has not less than five different accounts to access various parts of their infrastructure, none of which are connected at all. I assume people there listened to "switch to OIDC" nonsense, completed half the job, and now have OIDC sites and SAML sites forever.)
3. Discovering the SaaS vendor knows how Entra works, how Okta works, and how Google auth works, and having no idea how SAML works. Or OIDC or anything else for that matter.
4. Eventually finding an engineer far enough from the sales and implementation teams who can answer how the product actually works. :D This point is reached after a lot of yelling.
If I’m paying for at least one Senior to build and support this awful enterprise authentication pattern, I’m looking at around 200k per year in total cost - you damn well bet I’m billing you for it!
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.
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.
Saml is just not reasonable in our modern security environment.
https://www.war.gov/News/News-Stories/Article/Article/428899... (Microsoft has solely discontinued this practice for the DoD tier. Commercial, GCC, and GCC High are still impacted because foreign labor is cheaper than the risk to your security.)