3

Im trying to wrap my head around the difference between SAML/OIDC/and OAuth

Is the only reason SAML is the most popular choice for enterprise SSO that its been around much longer? Is it expected to eventually be replaced by OIDC and OAuth for SSO OR is there something inherent to SAML that makes it better suited to SSO than OIDC and OAuth? SAML uses SOAP which has been pretty much 100% usurped by REST which OIDC uses so I would expect SAML to also be replaced by OIDC.

It seems like SAML includes support for authentication and authorization if the SP is written to read SAML attributes and use them to determine what access the user has.

Open ID Connect only supports authentication and must be used with OAuth to include authorization right? Does that make SAML easier to configure usually?

This isn't an open ended question about which is better, Im asking if SAML is inherently better suited for enterprise SSO or is only still popular for historical reasons. I've been reading articles like this one that say stuff like "Ideally, organizations are going to use both SAML as well as OIDC depending on the use case." and I don't understand why because the overlap for SSO use cases appears to be 100% to me. It feels like we are "stuck" with SAML because its more widely supported for enterprise systems- at least for now. Is that an accurate assessment?

EDIT: Trying to find more info about this and this article is really helpful especially, but this still confuses me:

"SAML is still our preferred approach and I think the best approach, when a user is trying to get to a resource in a browser," says David Meyer, vice president of product for OneLogin. "It is super-efficient and super secure. People say SAML is dead, but we see it exponentially increasing in adoption every year. Literally, exponentially."

I'm having trouble understanding what makes it better or more efficient and secure than OIDC with OAuth

The article also reminded me of Open ID 1.0 years ago and how it died. That death and resurrection as Open ID Connect was important historical context missing from the other articles I was reading.

Basically what I want to get to the bottom of is if the SSO use case can be fully serviced by OIDC at least as well as it is by SAML- Im pretty sure at this point it can be, but reading some confusing stuff about it.

3
  • There isn't really anything "wrong" with SAML as a protocol. Just because OIDC is newer doesn't mean it's better. It's just newer. Inertia will keep SAML going - probably forever, with how old it is - but that isn't a problem unless an inherent weakness is discovered in it (implementation issues aside - some vendors I've worked with that rolled their own SAML implementation definitely scared me).
    – flashbang
    Jan 6 at 19:58
  • This is the entire reason I asked this question. If SAML is inherently better suited for this than OIDC or not. A lot of info online just says it is with little to know explanation which is confusing and frankly wrong. The reality it seems is that it is not inherently better for this purpose but just got there first so there are mostly important biz reasons to implement it instead of or in addition to OIDC. Jan 6 at 20:07
  • From a functionality and security standpoint, no, they are equals (although see the note about IdP-initiated authentication below, there are some slight differences). SAML came first though, so that's why it's still used. Many organizations also already support SAML, and don't want to invest time in setting up OIDC since there is no real impetus to change, so vendors support either SAML or both because they don't want to miss out on customers.
    – flashbang
    Jan 6 at 21:44
3

I'm not sure this completely explains the enduring popularity of SAML, but it's worth noting that the SAML standard defines at least one scenario that OIDC does not: IDP-initiated authentication. This is when an originating application crafts a SAML response, signs it, and posts it to the partner application. In this setup, the originating app is the "IDP" (Identity Provider) but doesn't really need the typical amount of IDP infrastructure, but just the ability to craft the right SAML, sign it, and send the user on their way.

There are arguments to be made that IDP-initiated is less secure in a lot of scenarios, but the fact remains that it's simpler to implement for many teams.

Beyond that, my opinion is that the popularity of SAML is largely due to industry inertia: it works well and it's critical infrastructure so why take the risk of trying to replace it with something else.

5
  • "Beyond that, my opinion is that the popularity of SAML is largely due to industry inertia: it works well and it's critical infrastructure so why take the risk of trying to replace it with something else." this is what I suspected. there is just a lot of confusing info online that clouds this Jan 6 at 20:07
  • That seems similar to what can be accomplished with JSON Web Tokens (JWT). The JWT is the ID Token of OIDC. What do you think? Maybe there is a more nuanced difference in your answer that I don't see? Jan 7 at 16:31
  • @Todd yes, similar, but the difference is that the SAML standard defines IDP-initiated at the SSO protocol level, just just the token format.
    – explunit
    Jan 7 at 20:11
  • The user of a mechanism with the essential features (JWT) presumably makes it feasible to accomplish the same thing with OIDC. Perhaps the difference is that SSO explicitly defines the protocol? Thanks Jan 7 at 23:57
  • 1
    @Todd Yes, the difference is the standardized protocol. You can agree with your integration partner "I'm going to post an unsolicited ID Token to you, and it's going to be in the xyz parameter", but you can't point to a section of the OIDC spec that says it works that way, and you don't have any industry analysis of the strengths/weaknesses of said approach.
    – explunit
    Jan 8 at 14:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.