8

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.

Improve this question
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, 2021 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.
    – user1028270
    Jan 6, 2021 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, 2021 at 21:44

2 Answers 2

Reset to default
4

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.

Improve this answer
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
    – user1028270
    Jan 6, 2021 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?
    – Kind Contributor
    Jan 7, 2021 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, 2021 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
    – Kind Contributor
    Jan 7, 2021 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, 2021 at 14:04
-1

It's been a while since this question was posted, but here's an up-to date response.

SAML is not necessarily more secure than OIDC or OAuth2.0. Also SAML is not based on SOAP. SAML and SOAP are two different distinct technologies.

SAML is an XML-based standard used for exchanging authentication and authorization data between parties, typically in the context of single sign-on (SSO) systems.

Similarities Between SAML and OIDC

SAML and OIDC are similar in that they are both authentication protocols that provide users with a single sign-on experience. Both standards are highly secure and can be customized to improve user privacy by controlling which user attributes (called claims) are shared. In addition, both utilize a third-party identity provider to authenticate.

Implementation

SAML is more complex than OIDC, making it more challenging to implement. SAML uses verbose XML to exchange identity data. This creates heavier data handling loads. In contrast, OIDC is simpler to implement because it outsources encryption to HTTPS or SSL, which is already integrated on both the client and server sides.

Here's a comparison table that outlines the differences between OAuth, OpenID Connect (OIDC), and Security Assertion Markup Language (SAML) in terms of authentication and authorization:

enter image description here

SAML or OIDC? Which One Should You Choose?

OIDC and SAML are both powerful authentication protocols, each having unique features and benefits. Below are some factors to consider when deciding which one best fits the needs of your organization.

If fast and easy implementation is your primary consideration, choose OIDC. It is much simpler to get up and running than SAML.

If your organization uses an API-centered architecture, OIDC will provide a better experience for users of native and single-page applications. OIDC is lightweight and more performance-friendly than SAML.

For large enterprises that require a higher level of security, SAML might be the better choice. SAML allows multi-factor authentication. It is a more mature standard with a proven track record and more feature-rich than OIDC.

The Future (as of today)

The future is definitely OAuth 2.0 and OIDC. All major SSO providers are focusing on identity protection mechanisms and completely remove passwords from logins.

Speaking of which next level in securing personal user data will be to store sensitive personal user data in decentralized digital wallets utilizing mobile devices and data will be provided per login/registration request and will be permissive.

That is achievable through OpenID4 VCI.

OpenID for Verifiable Credential Issuance (OpenID4 VCI)

Defines an API for the issuance of a Verifiable Credential in W3C and ISO formats. This format uses OAuth 2.0, meaning existing apps deployed using OAuth 2.0 and OpenID Connect OPs can be extended to become credential issuers.

Example is PingOne NEO - Decentralized Identity service.

Starting with SAML? Check this out.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .