I feel like we keep making this mistake again and again. Like JWTs can be signed with the "none" algorithm, which as you might guess is very easy to forge. Conformant implementations can see that and say "yup, that's a valid signature" and happily let any user grant themselves any access they want. Big mistake. It probably shouldn't be in the standard.

(I like PASETO instead of JWT, but nobody else in the world does, it seems, so we're stuck with the broken thing forever. Client libraries at least special-case "none" now and make it auto-fail, which has probably saved a few people that didn't actually read the spec.)

Thanks for mentioning PASETO. It looks good, except that it doesn't have a standard way of specifying expiration like JWT. But at least it's easy and safe to roll your own implementation of that part. Edit: My mistake; it's just the Elixir implementation of PASETO that doesn't support expiration.

PASETO is a bit of an odd duck, and isn't really an answer to the OIDC vs. SAML question. OIDC relies on JWT in the same way that SAML relies on DSIG, but there's a whole authentication protocol build around it. You would probably not be better off replacing an OIDC implementation with a hand-rolled authentication protocol based on PASETO.

The big problem here is that none of this matters. People do abuse OIDC as a general-purpose token for individual applications, but almost nobody does that with SAML. The point of these schemes is to federate authentication. In other words: it only matters what Okta and Google will agree to do. Your options are OIDC or SAML.

If you had to pick between the two, I guess you should pick OIDC, and think about what Ryan Sleevi said downthread about certificate verification; you'll want some kind of pinning scheme (pinning is a mess in client-server situations, but still sane in server-server applications; in fact, server-server pinning long predates browser public key pinning).

If you're not federating authentication, I don't think you should use JSON tokens of any sort.

> The people who wrote the XML signature standard didn't just take an XML document and whack a PGP signature around the whole thing! They thought about use cases like 'what if you wanted to only sign part of a document' and 'what if, after signing, the document was processed by something that reordered the attributes' and 'what if you have signatures from multiple sources and want to collate them into the same document'. They decided they wanted to support all of them.

You forgot to add the part - what if someone wants to add comments randomly without it changing the signature, even when those comments (mildly) change how the xml doc is parsed!

I did forget. I've spent years trying to.

It's too late to reform SAML, but this where TDF shines. [1]

This is what we use in the military to provide provenance assurance, classification markings, and authorize dissemination destinations for digital intelligence products, and also what we use for manifests to enable trusted data transfers from unclassified to classified networks.

It's pretty interesting to be on a network where everyone has a PKI identity. Your client certificate gets sent to your sponsoring agency's personnel database, which returns the exact set of clearances you have, that gets sent to the server you're requesting information from, and you get back a web page with exactly what you're authorized to see and everything else redacted. No need to login and you can access any page you know the name or address for. You just may not see anything on it.

[1] https://www.dni.gov/index.php/who-we-are/organizations/ic-ci...

> 'what if you wanted to only sign part of a document' and 'what if, after signing, the document was processed by something that reordered the attributes'

Those use cases are valid. The second one is actually the reason why JSON can't be used for a similarly usage (there is not canonization standard, and reading then writing a file could reorder the elements order).

The problem isn't that there's no valid use case for it; it's that there's no use case for it in SAML, just as there's no valid SAML use case for XML comments (which also broke SAML).

You can defend DSIG in a lot of different ways. I'll disagree with all of them and feel like I could probably win the argument; DSIG is a cursed standard. But that's not the bar you have to clear in this discussion; here you have to establish that DSIG is good for SAML. It clearly isn't.

I might be wrong but I vaguely remember that something like “all” of the popular open source SAML libraries in the wild were vulnerable due to DSIG mishandling circa 2012. They’d blindly accept any document as valid as long as there was a signature in place that signed some element, but didn’t bother to check that that element was the set of assertions actually being used.

There were similar issues more recently (2018/19) with custom XML entities or comments. The XML signature was unaffected, but if code used the equivalent of element.children[0] to get the contents, it was possible for attackers to truncate the attribute values seen by the service provider library.

Yep. You still find variants of that today.

The latter is not a valid use case for anything using signatures, because it² is virtually impossible to implement correctly.

The former might be important for something? But generally also very nearly impossible to do correctly. When that is the case, one should contemplate whether the actual business requirements can be fulfilled another way, instead of making things broken by design.

² "canonicalize-encode-sign" as opposed to the correct way of "sign blob, parse blob".