[Saaster]

Passwords, rate limits, resets, etc. are the same for everyone, and so are the problems and the solutions to those.

SAML on the other hand is different for each organization. Providers pay Auth0 and the like to have developers on staff who know the pitfalls and quirks of ADFS 3.0 on Windows Server 2012 R2, so they don't have to. Dealing with a single Okta as IdP integration is like the absolute best-case scenario there is. There is also zero consistency in what actual data IdPs returns out of the box to the SPs, so now you're walking the customer's admin through setting up the proper attribute mappings, etc.

I also very much disagree that SAML is a net security benefit, at least directly. It's for convenience, top-down visibility and control into what people are using, de-provisioning services, onboarding and offboarding users at scale etc. e.g. problems that only big companies have. Many SAML implementations are just as likely to add truck-sized security holes to the service provider when done poorly, and a lot of them are done poorly.

[tptacek]

It's a little odd to say something is not a "net security benefit" and, in the next sentence, make a powerful case for it as a net security benefit. SSO is probably the most important organization security tool there is, and a survey of tech company CSOs will average it in the top 3, if not the top 2 technology acquisitions most would make at a new firm (this is a question I've actually surveyed).

[Saaster]

SSO is a great benefit to the customers, with real tangible security and management benefits.

I'm however speaking from the point of view of the service provider (the SaaS app) and about SAML in particular. I feel that the addition of SAML into a given service is a net-negative from that service's security point of view. It's a large additional complex attack surface, many open source SAML libraries that I've reviewed have a history (and in some cases open issues right now) of "pants on head" type of security errors. A popular library in use right now, has a known race condition where it gets confused if there are concurrent SAML requests happening.

And that's just the libraries. Then you have to use them correctly. The libraries do the absolute minimum checking since they don't have the context, you have to add a laundry list of your own checks to them. Just recently there was a HN article about taking SAML assertions posted to provider A and re-using them on provider B, where clearly the most basic of checks aren't in place at all. There's all kinds of confused-deputy type of problems I believe most service providers don't think about at all. And that was an easily offline checked attribute, I believe if you'd start to check how many services correctly implement even the basic "inResponseTo" check on SP-initiated flows (which requires a distributed cache on the service provider side), you'd find they don't.

[tptacek]

I'm a security researcher with a minor focus in SSO libraries, working on OIDC and SAML right now. I've discovered and reported some of the kinds of issues you're referring to. Both OIDC and SAML are fraught in implementation, but so are all login features.

Meanwhile: we're discussing Github, not a random cat-sharing startup. Github has one of the larger security teams in the industry. The parties implicated in Github SAML are Github, Okta, and Github customers, who do not actually have to implement SAML. Github SAML is not in fact a net-negative for security.

[Saaster]

100% agreed, GitHub SAML is unequivocally good. I'm in the "cat sharing startup", so my view and comments are colored by that perspective. Our options are to pay $$$ for a competent auth provider, or take on a much larger and complex security responsibility than it would seem at first, that might end up compromising our entire service.

I have a theory that one reason we don't see many your-SAML-implementation-is-completely-broken reports is precisely because it's a gated enterprise feature, so few independent security researchers have the access or ability to poke and prod at them outside of private penetration tests.

[tptacek]

The riskiest components in SSO deployments are SP-side libraries, and those are all open source. If you want to use Okta to drive those libraries, the trial account you need is free.

The worst bugs here are indeed mostly private, but that's because they're feature bugs inside of people's random products; they're like every other bug in that regard. But people do find and report bugs in the SP libraries.

I agree that SAML is risky to implement; since we agree that Github SAML is an unalloyed good thing, we'd be searching for reasons to disagree at this point.

[user5994461]

I'm surprised you'd say SP-side libraries are open source. In my experience, it's always been mostly custom and close source in every company I've seen and done.

You take some open source pieces you can (saml, xml, oidc, ssl, jwt) but permissions, groups, user attributes, keys are always per company then the whole thing together has to be supported into end-user applications running on language and frameworks of the day with their own restrictions, so custom.

[user5994461]

What's are the other contenders for top 3?

[tptacek]

MDM or endpoint tracking, and then it gets diverse.