Just speaking practically, the biggest reason to support SAML is that customers use it.

Tons of companies still use old school Active Directory for SAML -- and aren't even quite ready to migrate to Entra (formerly Azure Active Directory).

> Just speaking practically, the biggest reason to support SAML is that customers use it.

This is a huge reason to support SAML, I agree. You can talk all day long about how OIDC is better, but if a customer or application only supports SAML, that's what needs to be implemented.

Especially since single sign-on is usually an enabler, not the whole value proposition of any application.

This only supports my point of considering SAML as being "ancient" - but I just don't know if it's true.

It's just a feeling seeing it mostly in banks and other old-school enterprises (AD plays a huge role here as you mentioned)

Not even close. Pretty much every enterprise uses it because, from an admin point of view, it does everything the customer wants. Centralised user management is pretty much mandatory for different compliance and AD and Okta meet those needs just fine.

Hell, from a user perspective, I don’t even hate the Okta SAML implementation now we have support for Yubikey enabled. Click a button, I’m in.

I certainly won't defend saml (it does suck), but saying oidc is a breath of a fresh air seems like an overstatement :).

Multilateral federation is SAML's killer app, and why higher education still uses it instead of OIDC.

I hope there will be some changes on that soon, have a look at https://openid.net/specs/openid-federation-1_0.html.

Ha, just found out you already posted the spec. Still, even if it gets published, IMO multilateral federations will migrate veeeery sloooooowly.

The beauty of this spec is that it defines a set of basic components to build multilateral federations between various types of entities (without a need to rely on Web PKI + of course, the types of these entities are limited by the imagination only). Regardless of what's going to happen and what isn't going to happen to existing SAML multilateral federations, I think this this specification might begin to be adopted for various other use cases.

It's worth mentioning, the spec was also written by people who aren't new to anything from that, they were already deeply involved in SAML multilateral federations.