SAML: A fractal of bad design

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.

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.

You've lost me here due to my experience with Kerberos and OAuth (JWTs specifically), though I mean JSON, not XML, so if by "marked-up" you meant "XML bad", well, that I would agree with.

Kerberos has something of a "markup" in that it has typed holes for carrying all sorts of useful metadata about the subject, especially what it calls 'authorization-data', but a) it's a real pain to get KDCs to include useful site-local things, b) it's remarkably harder to get Kerberized services to be able to get at that authorization data! (b) is surprising. I worked that problem for a bit -- I've done a lot of work on Kerberos, but APIs involve lots of work, not just C but Java, Python, all the things, so the last mile requires a ton of work to bridge, and then you end up with a pile of {some kind of data type ID, data encoded accordingly} that the application has to decode, so you have to:

  - specify syntax/encoding for your site-local authz data
  - write KDC-side code (preferably just plugins)
  - implement RFC 6680
  - including language bindings for various langs
  - implement authz data decoders to use in apps
  - use those decoders in those apps

Now compare to JSON: when you're done validating the signature or MAC, or decrypting the token, you now have a JSON text for the claims. Injecting site-local claims in your token issuer is trivial now. Using them in your applications is even more trivial (provided you have a JWT validator, otherwise it's too trivial if you forget to validate the signature!).

JWT got this right. Kerberos got it wrong.

In defense of Kerberos, it goes back to the mid to late 80s depending on which version you want to start counting at, and GSS-API goes back to the early- to mid-90s. So we're talking 30+ to 40+ years, all of it predating JSON and XML.

But today, in 2026, Kerberos is indefensible. Kerberos is still necessary, yes, because there are specs for and support in so many useful application protocols and implementations thereof, and because of Active Directory.

The lesson I draw from this is that GSS-API in the mid-00s needed to have grown a version of `gss_accept_sec_context()` that outputs a JSON text. I wish I could go back in time and build that.

So, yes, authentication context metadata, including metadata useful for authorization, can and should be represented in a "markup" language, specifically JSON.

IndieAuth exists, it's just not widely supported.

"Host your own identity"

It’s like “using JSON” but actually encoding objects indirectly through your own made up object notation… that is structured.

If anyone could attest to who they are at any time we could just have user/pass without email and call it a day.

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.

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.

I mean … how else would you check a signature? You have to have the data to validate the signature.

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.

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

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.

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.

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.

We should remember that we learn by failing.

Edit: When I first read the comment, XML part was not there, but I don’t agree with the XML part of the comment, because JSON to XML is Python to C. While both can carry data, XML is designed to handle more than that. Especially validation and transformation parts. If you don’t need these, it’s an overkill, but if you use them, it’s a perfectly fine format. It’s even elegant and batteries included.

Also, you can parse it in an instant. I have designed XML based file formats which would fall apart in JSON and YAML.

The XML debates sounds to me like calling a space shuttle complex because one only needs to go to the mall downtown.

That is a workable if coarse description of OIDC, which kind of fits your SAML vs. OIDC framing, although I’m pretty sure that’s not what you meant to imply.

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.

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.

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.