Specific differences between Federated Authentication with SAML compared to OpenID Connect Auth Provider for SSO to SFDC

Question

I've successfully tested SSO against Azure AD / O365 using the approach illustrated on this developer.force.com post, which uses an Auth Provider and the OpenID Connect Provider Type.

However I see a lot of information around Federated Authentication with SAML, and the Salesforce SSO implementation guide is heavily tilted to SAML.

There is a good bit of information around OpenID connect vs SAML out there on the internet. I've read posts indicating that openId Connect can do all that SAML can, but is more lightweight and easier to work with, is better for mobile apps, and is the future.

The Security Assertion Markup Language (SAML) is an XML-based federation technology used in some enterprise and academic use cases. OpenID Connect can satisfy these same use cases but with a simpler, JSON/REST based protocol. OpenID Connect was designed to also support native apps and mobile applications, whereas SAML was designed only for Web-based applications. SAML and OpenID Connect will likely coexist for quite some time, with each being deployed in situations where they make sense.

However, I have not been able to find good coverage in terms of what the Salesforce-specific considerations are.

I have been focused on OpenID connect, so my knowledge of SAML is limited, but so far what I've found re: SFDC-specific implications is that both are similar in most ways, including

• Both offer just-in-time user provisioning with developer-configurable logic
• Both can update existing user data
• Both let users login using the Active Directory credentials

And they differ in at least one:

• I believe only Federated Authentication with SAML currently allows you to control (force) specific users to authenticate via SSO by permission set.

As I determine what path to take for this project, it would be really helpful to better understand the salesforce-specific implications of these two options that would let me choose one path vs the other.

I have not looked deeply at delegated authentication because it looks like more of a beast, so if there is a compelling reason to look at that as an option for basic SSO against Azure AD i'd be interested to hear it.

Answer 1

For Salesforce, there are two types of SSO: SAML is Single Sign On, OpenID is Social Sign On:

With SSO, users can access services without logging in to each one. With social sign-on, users can access a service using their social account credentials.

With social sign-on, users log in to a Salesforce org with their username and password from an external authentication provider, like Facebook, Twitter, LinkedIn, or Google. You can set up any of these providers with a few clicks. With a little bit of work, you can set up other providers, like PayPal and Amazon.

Social sign-on is especially useful when you want customers to be able to log in to a community without having to create (and remember) a new username and password. Customers can log in to a Salesforce community using their Facebook or LinkedIn account.

Single Sign On is authorized by your company, whereas Social Sign On is authorized by another company.

References

• Trailhead: Identity Basics

• Differentiating Federated Identities: OpenID Connect, SAML v2.0, and OAuth 2.0 – Software Secured