[fabian2k]

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.

[tptacek]

We've managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they're selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you're often competing with companies that don't do real SSO integration at all.

At the very least: if I was ever to do SAML, I would rip your face off in the pricing for it.

[mwcampbell]

If by "we" you mean Fly, can you tell me if Fly happens to be implementing OIDC (or reusing a third-party implementation) in Elixir, Ruby, or another language? I'm curious about what Fly in particular is using because I know that Fly has invested pretty substantially in Elixir and Phoenix in particular, and I've got a Phoenix app where I want to implement OIDC. We previously implemented SAML by literally using Shibboleth SP. Thanks.

[xyzzy_plugh]

There's a surprisingly long line of folks who would gladly get their face ripped off for SAML. In my experience, it's worth it.

[bitexploder]

Lol, yeah, having SAML means putting XML parsing into critical security points. No thanks.

[poincaredisk]

Is it that different from parsing JSON? A honest question, what's the difference? Billion laughs attacks and similar?

[tptacek]

It's not just XML formatting; it's bizarro stuff like XML canonicalization and comments, and it's in a signature format. It really might be the worst mainstream cryptosystem in the entire industry.

[Jerrrrrrry]

A computer scientist would say they have identical parsing complexity, so not much.

A computer programmer wouldn't even know where to begin, as the chesterton's fence had long been rejustified

[bitexploder]

But it’s not true in practice. Pure simple XML vs JSON sure. XML you deal with in SAML has tons of extra things like namespaces, canonicalization issues, etc. it is way more complex and has led to many security issues over the years.

[Jerrrrrrry]

I had originally quoted

  "in theory, it's easy in practice. in practice, its easy in theory"

But I thought scientist vs. programmer would be literally analogous and rivet more finches.

[bitexploder]

Yeah, see the other replies in here. It is just a mess of ancient cruft and unclear implementation guidelines.

[robmccoll]

Even better: XML signatures, which are very easy to get wrong in both signing and verification.

[bitexploder]

Yeah, it is a gross morass of pain and cruft and unclear implementation for devs.

[galdor]

Microsoft Entra having first class support for OIDC really helps; I remember seeing a decision diagram in their documentation recommending using OIDC for new projects, it can help negotiating. Google Workspace also works just fine with OIDC, and so does Okta.

I've been told that the only source of problems is going to be companies using Shibboleth, even though there seems to be an OIDC plugin.

[ned_at_codomain]

Yeah, SAML will probably fade away (slowly). And sometimes, you might be able to convince the customer just to use OIDC.

But human behavior change is hard and expensive. For the most part, it's just easier to give the customer what they're asking for / what they expect, even when you know they're wrong.

When you're trying to push an enterprise deal over the finish line, this is often just not a good enough reason to introduce friction with your buying committee.

And if you have to support SAML for one stubborn customer eventually, you might as well support SAML for all customers that really want it.