SAML: A Technical Primer (opens in new tab)

I don't think artifact binding really addresses many of the issues people are talking about when they suggest OIDC is categorically more secure than SAML.

SAML is an unfortunate a necessity in most enterprise environments. There’s almost always something, usually more than one, where SAML is the only option. I do think in 2024, everyone should also offer SAML alternatives in parallel .

> because it does not only rely on cryptography while validating the token

When using PKCE the relying party can use JWKS to validate the token instead of talking to the IdP.

Are you suggesting that, that is somehow insecure?

I don't know a lot of security engineers that agree, and while (as a SAML implementor) I have my own opinion, "don't do new SAML implementations" is mostly me parroting what I think is the consensus.

I think... it probably is as cut and dry as I'm suggesting.

What about OIDC does not scale?

The things you just listed sounds like unnecessary complexity that inevitably leads to the “too big standard” problem, where every vendor and id provider has their own half assed, incomplete and incompatible implementation of the standard, or worse - with security bugs. Something quite often seen with SAML.

That’s not to say that oidc or oauth doesn’t have alignment issues. See https://news.ycombinator.com/item?id=35713518 “We implemented OAuth for the 50 most popular APIs. TL;DR: It is still a mess”

This cuts both ways. The last major revision of SAML predates the iPhone by several years. Things like PKCE, which are essential for security on mobile devices and in other cases don’t exist at all in SAML, yet the same attack vectors apply (plus a boatload more).

I gather that you've fired every CISO you've ever had.

Do you mean chooses it over OIDC, or even when a product can only do SSO via SAML?

> Let's just say my interaction with managing websites that used SAML was less than pleasant.

My interactions supporting it as both the identity provider & the service provider have lead to me being the SAML person at work, and I'm now very used to people either laughing at my misfortune or giving me pitiful looks.

It combines all the wonderful antipatterns you can name: a protocol where near everything is optional and two standards-compliant implementations can refuse to cooperate in any number of ways, hair raising security decisions (XML-DSIG?! configurable crypto? ughh), and half-baked features (back-channel SLO, anyone?)

It's a Lovecraftian horror that actually makes me appreciate JWTs.

As someone who worked at a very large SaaS company this is a good recommendation if the vast majority of your customers come from large enterprises with competent IT departments.

The problem is when you work with smaller shops that don’t have IT departments or worse bad IT departments you’re going to pay a fortune in support costs.

Use an open source identity provider or pay someone to do it for you.

Everybody who worked with it knows that S stands for Shitty.

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.

Could you elaborate? I'm interested.

That was my understanding and also my plan, but it does not seem feasible to force this as the vendor of the software. If the customer says they need SAML at some point the business side will require that it is implemented. I do want to try and get as far with only OIDC as possible, but I am a bit worried that some larger customer might just bulldoze through because they only want SAML. Might be much more likely for on premise cases, if you're in the cloud you probably use an identity provider that supports OIDC already.

FWIW back in the day, samltest.id was a dummy IDP, whereas sptest.iamshowcase.com is a dummy SP. You could hook these two up to each other and see the whole flow.

We've found some usage of http-redirect and support it. But we've gotten requests for Artifact and other more esoteric features (encrypted assertions). It's definitely an example of the 80/20 rule.

> We just implement SAML RelayState / OAuth `state` via good old database persistence.

I'm not sure I understand how this helps. You still need to support the parameter so that folks can pass information through the login state (for deeplinking, among other use cases). Which means you still need to process it and therefore are committed to either being noncompliant with the spec or providing functionality that is limited to 2005 sensibilities.

What am I missing?

> a big part of SCIM is just the deprovisioning aspect?

The "just" makes it sound like this is a minor point. This is a huge point. Enterprises are forced by their customers and regulators to show that terminated employees lose access immediately. There are two ways to make that happen: force everything to flow through a VPN, and SCIM. Most SaaS providers do not support IP allowlisting needed to enforce that all traffic flows through the VPN, and the only alternative to enforce that user sessions are terminated immediately is if the SaaS keeps sessions in a database and those sessions are revoked as part of SCIM. Otherwise the sessions could continue to be valid for days or even longer, presenting a risk of allowing terminated employees to wreck untold havok.

Mire:

N. a complicated or unpleasant situation from which it is difficult to extricate oneself.

Indeed.

Ah, thanks for that clarification.