This is a very weird page, as it seems to suggest that SAML is the only way to do single sign-on integration with IdPs like Okta. But modern systems all do OIDC, which is what you should do. You need a much better reason to support SAML than "the CISO wants it so they can use Okta", because the CISO can (and should) just use OIDC.

Surprisingly the page doesn't explain the meaning of SAML. It's Security Assertion Markup Language https://en.wikipedia.org/wiki/Security_Assertion_Markup_Lang...

Everyone in here is saying SAML is dead and long live OIDC. The company I work for has SAML support, but not OIDC. As far as I understand it, all the customers are asking for SAML. I've never heard a request for SAML. This is in the health care sector.

Cryptographically authenticating SAML assertions is the most perilous part of implementing SAML

The incredible overengineering of the XML signature specification is certainly to blame for this recent SAML verification vulnerability (from the same site): https://news.ycombinator.com/item?id=41586031

If the customer is using an identity provider like Microsoft Entra, is there any reason not to just use OIDC instead of SAML?

I really wish that OIDC / Oauth(orization) would be less confusing from user experience and security perspective.

What I have in mind - I'd say only very small population understand that OIDC / Oauth(orization) is about granting access to a service to access your data. Meaning once you have approved service (lets say Dropbox), now Dropbox can access your data on your google account (this of course depends what exactly dropbox asked and if you clicked on "approve", but most people do click as they want to login to Dropbox via their Google account).

SAML is better, as it can be defined at Google side what data is being sent to DropBox when Single Sign On happens and DropBox cannot access your google data as it sees fit.

SAML ain't perfect either because there's no practical way to "sign me out everywhere"

Also worth noting that per the spec, the RelayState can only be 80 bytes.

> As well in "HTTP Redirect Binding" or "HTTP POST Binding", The RelayState value MUST NOT exceed 80 bytes

From https://docs.oasis-open.org/security/saml/v2.0/saml-bindings...

At FusionAuth, we have an open issue for this: https://github.com/FusionAuth/fusionauth-issues/issues/2467 which you can read for more details.

SAML is full of these kinds of gotchas. We have an open source library which provides Java SAML bindings: https://github.com/FusionAuth/fusionauth-samlv2

No reference to SCIM?

OIDC is far preferable to SAML, but the last time I touched this, half the reason why customers preferred SAML was because their IdP supported SCIM but only for SAML applications.

SAML-snark aside, this is a great primer. Definitely useful in explaining to different stakeholders what we're talking about when we talk auth.

> You care about supporting SAML because your customer wants your product to support SAML. This is sound reasoning on your part.

Is it just me or is anybody else going 'the fuck did I just read?' here? It's... incredibly condescending?

Since we're here, I hope someone creates another all encompassing SP/IDP emulator like samltest.id used to until the owner stopped paying. That made my life so much easier as a developer when SAML stuff came up. No one else has come close.

> What is the point of SAML?

> You care about supporting SAML because your customer wants your product to support SAML. This is sound reasoning on your part. But why does your customer want SAML support?

> One click to login: why your users like SAML

What? No, the users don't know about SAML.

Anyways, no, users don't like SAML. OIDC has a much nicer UX.

[dead]