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!
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.
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.
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?'.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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.)
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.
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?'.
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.
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?
Implementing all the main authentication mechanisms is hell.
Oauth2 is utter utter shite as well.
Why are you using an authorization protocol for authentication? Try OIDC.
OIDC is a layer on top of OAuth...
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.
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 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.
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.
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.
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.
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?
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
That's what the original OpenID (from back in the LiveJournal days) was supposed to be right?
"Host your own identity"
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.
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.
IndieAuth exists, it's just not widely supported.
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.
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.
I'm almost convinced already, but I have the professional duty to at least read why
Ok, I'm convinced
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.
Waiting for the "OIDC: Time for Authentication to Take a Xanny" article
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.
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.
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/
This is one of my favorite articles. I refer back to it whenever the subject of PHP comes up.
Have you kept up with the improvements in the latest PHP versions?
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'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.
Because you asked that, the article is now called "SAML Considered Harmful"