What use does SAML still hold with the advent of OIDC? When building enterprise software, should I bother implementing SAML or is OIDC support commonplace?
Anecdotal from my experience in Presales selling Enterprise software. Out of 10 enterprise segment customers:
- 8/9 would prefer SAML
- 2/3 have a compliant IdP which supports OIDC (ADFS needs to be v4.0 therefore run on Windows Server 2016+)
You'd be a fool to only focus on OIDC, at least for the next few years. As Azure gobbles up the Enterprise segment, Azure AD can be used to provide OIDC which will be nice. Though most admins who we work with are far more comfortable with SAML.
To be completely honest, the major of customers who are primarily interested in OIDC are coming from Google and/or GCP shops (which are few and far between).
In my experience with enterprise SASS products they mostly use SAML and most companies I work for use it. At the time I was trying to switch to OAuth or OpenID but the support was severely lacking for off the shelf enterprise software, especially older stuff. ForgeRock was also giving the identity management team issues so SAML was the only option.
In the Enterprise space you will definitely want to offer both. Most enterprises still sadly leverage ADFS which is SAML2.0. Fortunately a ton of shops are adopting cloud IDaaS, so OIDC is becoming the standard (mostly because SAML for native apps is awkward)
Everyone supports SAML, not everyone supports OIDC, and for everyone besides GSuite SAML is absolutely still the default even from the IdP side.
There's a subtle difference where the de facto best practices deployment for SAML includes cryptographic audience restriction: each IdP/RP pair generates a key just for that interaction. With OIDC, GSuite (or whatever) authenticates you to the RP. With SAML, _a SAML configuration on your GSuite install does_. You want this, because optional (largely: non-cryptographic) audience restrictions fail more than half the time and when they do they fail open.
(If you're thinking "if that's true why isn't all of this just Kerberos": you're not wrong, at least from a protocol design perspective.)
I like SAML because it does not involve http requests to fetch user profile (unless I'm missing something and OIDC allows that too). The whole user profile comes with the signed or encrypted payload.
As a result you can have identity provider sitting in an unreachable / private network.
Or.. Your identity provider doesn't even have to be a network service at all. We have some integration tests around systems using SAML for authentication. SAML authentication statements in test environments are generated by the test suite and fed to SPs via Selenium controlled browser.
The OIDC "id token" is a JWT that contains identity assertions, just like SAML would. You can go fetch the profile via HTTP, but that's mostly because major providers have quietly conceded that JWT is a nightmare, and encoded that fact in their API.
Major IdPs tend to provide an endpoint where you can send them the JWT, they validate it and return its contents as a plain JSON response. You're effectively trading JWT parsing for HTTPS.
They can't walk JWT back now without breaking existing apps, because parsing it yourself was advertised as an option.
SAML is more common in enterprise, it's a tad older and it does dual way authentication that OIDC can't do (the enterprise and the auth provider both sign messages and whitelist one another).
However OIDC is catching up quickly. It's supported by ADFS 2016, Azure, Google and all major IAM products now. It's also a lot easier to integrate, to use and to debug.
So both will be supported by all companies over the coming decade. Even dinosaur companies like banks that are very backward, because they follow Microsoft lifecycle.
If you are doing enterprise software I think you’ll find OIDC support less important - I don’t think most enterprise IdPs support it.
If you want one target: you’ll want SAML to federate against ADFS. That gets you going with an open standard and targeting one of the most common IdPs.
Yep and I'll add my experience at UNC was stellar where we allowed users to self-service AD via Grouper[0] and then Ping sourced information from there. It was integrated with AWS IAM and several other services, too.
