Single Sign-On Use Cases
When you want users to move seamlessly between Salesforce orgs and applications without logging in repeatedly, set up single sign-on (SSO). Depending on the use case, you can configure SSO so users log in to your Salesforce org from a third-party application, such as a corporate portal. You can also set up SSO to allow users to log in to another application from your Salesforce org. You can even configure an SSO chain where users log in to a third-party application to access Salesforce and then use Salesforce to access another org. Or configure a less centralized login experience, where users can log in to multiple apps with the same user credentials.
Required Editions
| Available in: both Salesforce Classic and Lightning Experience |
Federated Authentication is available in: All Editions Delegated Authentication is available in: Professional, Enterprise, Performance, Unlimited, Developer, and Database.com Editions Authentication Providers are available in: Professional, Enterprise, Performance, Unlimited, and Developer Editions |
Salesforce as the Service Provider or Relying Party
If your company already has an identity provider or authentication provider, you can configure Salesforce as the service provider or relying party. Users are logged in to your org from an identity provider or authentication provider, which authenticates their credentials. For this use case, you can define an identity provider with SAML, use a predefined authentication provider with OpenID Connect, or create a custom authentication provider.
When you configure Salesforce as the service provider using SAML, authenticated users can flow from a third-party identity provider into Salesforce. For example, your company’s IT department uses Microsoft Active Directory (AD) as its identity provider. A user navigates to the org login page and logs in. Behind the scenes, the org acting as the service provider sends the user to Microsoft AD with a SAML request. Microsoft AD returns a SAML response containing the SAML assertion that authenticates the user. The user is logged in and taken to the org’s home page.
Predefined authentication providers use the OpenID Connect protocol to enable SSO from third-party apps. For example, you want users to log in to their org with their Facebook account credentials. So you configure Facebook as an authentication provider for the org. When users navigate to the org’s login page, they can select the Facebook icon. They’re redirected to the Facebook login page, where they can enter their Facebook login credentials. After Facebook authenticates them, the users are redirected back to their org and logged in. Salesforce supports several predefined authentication providers, like Apple and Google.
If your app doesn’t support OpenID Connect, you can use Apex to create a custom authentication provider.
Salesforce as the Identity Provider or OpenID Connect Provider
Salesforce can also act as an identity provider or authentication provider to third-party service providers or relying parties by implementing SAML or OpenID Connect.
For example, you build a custom Your Benefits web app that implements SAML for user authentication. You want your users to be able to log in to this app with their Salesforce credentials. To set up this SSO flow, configure the Your Benefits web app as a connected app. Define your Salesforce org as the SAML identity provider for the connected app. Your users can now log in to the Your Benefits web app with their Salesforce credentials.
You can also use OpenID Connect to enable Salesforce as an OpenID provider. For example, you want your users to log in directly from your Salesforce org to a third-party customer service app that supports OpenID Connect. Create a connected app for the customer service app, and configure Salesforce as the authentication provider. The Salesforce authentication provider uses OpenID Connect, so it acts as the OpenID provider.
Salesforce as Both
By chaining identity providers together, you can configure Salesforce to act as both the identity provider and the service provider. You can chain identity providers with SAML or OpenID Connect exclusively. For example, you want your users to log in to their org from Google, and then be able to directly access your mobile customer service app. To create a SAML-only chain, configure Google as a SAML identity provider for your org. Then configure your org as a SAML identity provider for your mobile customer service app.
You can also create a chain that implements both SAML and OpenID Connect. For example, you want your users to go from Facebook to Salesforce to Workday with SSO. Configure Facebook as the OpenID Connect provider for your org. Then configure your org as a SAML identity provider for Workday. Your users can now access your org when they log in to Facebook and then access Workday from your org.
Salesforce and Delegated Authentication
You can use delegated authentication to enable users to log in to multiple apps with the same user credentials. For example, users can separately log in to Salesforce, Google, and Amazon with the same credentials. Manage delegated authentication at the user permission level rather than the org level, so you can control whether individuals use delegated authentication or a Salesforce-managed password.
If your company has a central credential management system, like a Lightweight Directory Access Protocol (LDAP) server, you can integrate it with Salesforce to configure delegated authentication. You can also configure delegated authentication with a token instead of a password.
