Hacker News Reader

Comment by cameronh90 | Hacker News Reader

SAML sucks, but it still has a bunch of features for its specific narrow enterprise SSO use-case that OIDC lacks - most notably IdP-initiated flow. OIDC is a constellation of specs with inconsistent support across products, whereas the commonly-implemented subset of SAML is more-or-less stable in its mediocrity.

OIDC will eventually displace SAML, but if you're selling to enterprises you should really support both. Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.

View on HN

OIDC doesn't support IDP initiated flows for a reason - they're vulnerable to a class of attacks known as Login CSRF. An attacker can trick a victim into submitting an IdP-initiated authentication response linked to the attacker's account/session into the victim's browser profile on the SP. Think - Eve tricks Bob into signing in to Eve's PayPal account instead of Bob's. Bob, none the wiser, links his bank account. Eve now has access to Bob's funds.

IdPs that need to support an "IdP-initiated" user experience (like a portal or dashboard where users click an app icon) should instead have that icon link to a specific landing page on the SP that safely kicks off a standard, SP-initiated OIDC flow. IdP -> (SP -> IdP -> SP). Look at Okta's "Initiate Login URI" for an example of this.

SAML implementations can protect against this by turning IdP-initiated requests into an SP-initiated request. On the SP-initiated responses, there is an `InResponseTo` field that can be validated (or `RelayState` can be made to work).

The OIDC specification is pretty hand-wavy about how to prevent this attack as well. So don't assume all OIDC implementations do.

OIDC spec has a limited third-party initiated flow[1] that redirects to the RP (equivalent to SP in SAML), which then starts a regular OIDC flow that is indistinguishable from an RP-initiated flow.

This flow is safe against CSRF, since no authentication data is carried together with the flow. The only other safety issue I can see is using target_link_uri for CSF. The spec clearly mentions that this URL has to be filtered or ignored by the RP.

Instead of treating the (horrible) technical implementation as a feature, it addresses the real user-facing feature: I want to be able to click on a link on my IdP dashboard and be redirected to the app. The login would still be seamless, since you already have an SSO session active with the IdP.

[1] https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

I feel like there is an easy solution to login csrf with IdP initiated flows. The SP just gives a pop up saying - you are logging into X as user Y. Continue?

The has been proven again and again to not work. See for example HTTPS certificate warnings for which now there is a standard to ask browsers to not show a popup just saying "The server might not be the correct one. Continue?"

It's an easy solution, but it doesn't work at all.

I don't really think that is comparable.

For starters, users generally do not understand what a cert validation error means. They do understand what it means to browse to a website.

The cert validation error is in the way of the user's intended action. This popup would not be.

Fundamentally such a pop up is not a security warning. It does not indicate that something is unsafe. That makes a world of difference.

I think a better comparison would be when you exit an app, and the app prompts you if you want to save. That has generally worked well.

What is prventing OIDC-based IdP from initiating login? You just need to know the login URI:

https://openid.net/specs/openid-connect-core-1_0.html#ThirdP...

Does Tailscale support SAML? If not: why would any other enterprise product need to? Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.

I don't believe it's plausible for any non-specialist firm to implement SAML without grave vulnerabilities. I'm not sure I've ever seen it done well. It's been a minute since I've looked (I haven't consulted in several years, but, more importantly: most firms avoid SAML now), but I'm guessing that assertion still holds.

> Tailscale is like the sine qua non of modern enterprise products, and I believe it's OIDC-only.

I think you're drastically overstating Tailscale's share and ubiquity in the market. Maybe it's heavily represented in tech companies or those in The Valley but among rank and file normal companies not dominated by developers, they've never heard of Tailscale

I think you're wrong about this, that basically every F500 with an access VPN setup has heard of Tailscale, and further, despite their penetration being much bigger than "tech companies in the valley", my point was that Tailscale is a modern business that exists to make (at this point) large amounts of money, and they're not doing SAML.

(It is good that they're not doing SAML, because SAML is the worst security specification ever written, and very few organizations have ever implemented it safely).

And I think you're wrong about this too.

You're overestimating the importance of Tailscale, underestimating the importance of SAML to enterprises and completely skipping over the fact that the customer base that Tailscale has restricted itself to, probably doesn't use SAML to begin with.

Here, I'll share you my thoughts on Tailscale:

I don't use Tailscale. I don't care about Tailscale. I don't know what Tailscale is and I don't really care to know, but I know what SAML is and I know that I will keep using SAML for the foreseeable future, and I know I won't be using Tailscale.

"sine qua non" is hubris.

Agreed.

Pretty much every large enterprise (inc. half a dozen non-tech F500s) I've seen in the past 5 years has used either GlobalProtect or AnyConnect. Slightly further down the scale, you start to see some Prisma, Fortinet, or F5 as well. All of them support SAML, and market it as being a key feature.

Personally, I'd love to see Tailscale being deployed more widely, but I've only ever seen it deployed by tech companies.

There are a lot of smaller providers that will eschew some features, require a fairly limited integration surface (was the case with a lot of things with Slack integration before Teams' COVID explosion, for instance) to keep their support and development costs down

The best estimates I could find have TS at a 1-2% market share. And that was my point: You suggested "well if Tailscale can get away with not supporting SAML, anyone can!" and I think that's wrong. 98% of the market already is buying Tailscale's competitors, they can hardly do worse

I'm sure they can juice that a good deal more, but eventually they'll have to start picking off features that they have been avoiding to this point. Will that be SAML? Maybe not, most companies are on Entra ID which supports OIDC. The real tell will be when Tailscale either goes public or sells to private equity. When their backs are to the wall and they need to squeeze out another percent or two in growth and they have a big customer that must have SAML, then they'll do it

One of the issues I've run into with Tailscale OIDC is that an email domain must be mapped to a single tailnet. So if my IdP has consultants or if my domain contains multiple businesses with different tailnets, I need to do some domain mapping in my IdP and train users to login with that special non-email address.

This isn't strictly a limitation of OIDC, but I do see this issue more often with OIDC implementations. With IdP-initiated flows, the app doesn't need to know who's in my IdP ahead of time.

When we started C1.ai - 2020 - as someone who worked previously at Okta - I made a decision to only implement OIDC. (see article for all of the reasons). We were worried in the first 2 years, that some big enterprise would force us to implement SAML.

But it turns out, all the major IDPs support OIDC now. It's a non-issue.

You can use Keycloak as a SAML/OIDC -adapter.

> Both will pale compared to the amount of time you spend dealing with SCIM inconsistencies between IdPs anyway.

I think that's the real problem. Just tying up things with custom, system dependent configurations would probably be more predictable. Most people are probably happy to get the happy path running.

Eh, many of us do what I think you mean by "IdP-initiated flow"s with JWT. It's not OAuth exactly, but it's a thing.

Reply on news.ycombinator.com