I have implemented the server-side of OIDC to support the single sign-on for AWS account management. It was a breeze, around 200 lines of Go code.

I tried that with SAML (back then, it didn't require kludgy X.509 thumbprint management in AWS), and I ran away crying after a couple of days trying to understand why it fails.

I investigated both and implemented OIDC. It was difficult, but compared to the SAML and XML complexity, I'd say it was much easier.

XML is marginally more complicated than JSON: attributes and namespaces.

Apples to apples, is it's not much different. XSD is just as complex as JSONSchema.

Verbose? Sure.

But people love XML so much, they invented JS-and-XML (JSX). :shrug:

The problem is not XML by itself. XML adds a considerable amount of complexity to JSON[1] and when writing security-oriented software complexity matters quite a bit[2]. But this is still a level of complexity that can be managed. Most other XML-based protocols aren't as bad as SAML.

No, the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signature needs to be embedded inside the XML it's signing, instead of being attached to it, like every other signature standard on the planet.

[1] The added complexity is not just attributes and namespace, but also entities, DTD and processing instructions. If you want even the most basic type checking, XML schema becomes mandatory. This is important, since JSON doesn't need a schema for handling basic types, and in fact OAuth 2.0 and Open ID Connect do not rely on JSON Schema at all.

[2] See the OWASP cheatsheet for all the ways accepting XML input from the internet can put your application in danger: https://cheatsheetseries.owasp.org/cheatsheets/XML_Security_...

No equivalent document exists for JSON.

XML=JSON=YAML=TDL (tree describing language)

Not really.

But pretty close.

> If you want even the most basic type checking, XML schema becomes mandatory. This is important, since JSON doesn't need a schema for handling basic types

Huh?

> the main problem with SAML is that it relies on XML Signatures (XMLDSig). And the main problem with XML Signatures is that the signature needs to be embedded inside the XML it's signing, instead of being attached to it, like every other signature standard on the planet.

You are correct that is the hardest part of SAML, but to be clear, there's a SignatureValue element that is separate from SignedInfo.

And you can use a library to sign. I don't see many implementing their own JWT signatures either.