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.

Didn’t JWT have a similar thing, where you could specify the algorithm to use and that included “null”?

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.

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.

> 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.

That's what the original OpenID (from back in the LiveJournal days) was supposed to be right?

"Host your own identity"

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.

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.

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.

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 has audience checks and selectable algorithms. I don't like JWT, but it's no XMLDSIG.

What's an example of a well-tested and well-written library that only supports a (good) subset of SAML?

> … 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.

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.

> 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.

There’s such a thing as a blunt, unwieldy dangerous tool. It gets the job done. Also people using it are torturing themselves.

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.

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 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.

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.

That seems like a bit of an arbitrary line to draw, no? Would you say the same about webhooks?

That mindset is indicative of security theatre to me. But as security theatre is common in entrprise IT that does not surprise me.

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.

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?'.

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.

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.

You use Entra. Entra can do jwt’s.

Saml is just not reasonable in our modern security environment.