Single Sign-On

When you set up SSO, you configure one system to trust another to authenticate users, eliminating the need for users to log in to each system separately. The system that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider.

For example, you can configure Google as an identity provider to authenticate users accessing your org. So users log in to your org using their Google credentials. In this example, your org acts as the service provider, trusting Google to accurately authenticate users.

You can configure your Salesforce org as an identity provider, a service provider, or both. For each of these use cases, you select the authentication protocol to use. Salesforce supports SSO with SAML and OpenID Connect. Salesforce also has preconfigured authentication providers that you can use to enable SSO with systems that have their own authentication protocols, like Facebook. For more information, see Single Sign-On Use Cases. To see a SAML SSO implementation where Salesforce is the identity provider, watch this video.

You can also set up a single identity provider to authenticate users for multiple service providers. For example, you can enable your org as an identity provider and configure Workday and Office 365 as service providers. Users can then access your org, Workday, and Office 365 with one login.

After you configure SSO, set up Single Logout so users can log out of a service provider and identity provider at the same time.

• 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.
• Single Sign-On Terminology
  Do you want to configure single sign-on (SSO) for your org? Get acquainted with some key terminology first.
• FAQs for Single Sign-On
  Review these frequently asked questions (FAQs) to help you implement and troubleshoot single sign-on (SSO).
• Require Users to Log In with Single Sign-On (SSO)
  By default, when you set up single sign-on, users can log in from the SSO provider or from Salesforce. To ensure that users can’t bypass your SSO system, disable their ability to log in with their Salesforce username and password so that they’re required to log in with SSO. We recommend that you don’t require SSO for Salesforce admins so that they can still access Salesforce to respond to SSO outages or other issues.
• SAML Single Sign-On Flows
  When you set up single sign-on (SSO) with Security Assertion Markup Language (SAML), you can initiate login from the service provider or the identity provider. Service provider-initiated login and identity provider-initiated login use different flows, but both result in the user being logged in to the service provider.
• Salesforce as a Service Provider
  Configure single sign-on (SSO) so users can log in to your Salesforce org with their credentials from an identity provider or authentication provider. For this use case, you can define an identity provider with Security Assertion Markup Language (SAML). You can also use a predefined authentication provider, configure an OpenID Connect authentication provider, or create a custom authentication provider.
• Salesforce as an Identity Provider
  Configure single sign-on (SSO) so users can log in to an external service provider or relying party with their Salesforce credentials. You can enable your Salesforce org as a SAML identity provider and integrate a service provider as a SAML external client app or connected app. You can also use OpenID Connect to integrate a relying party with your org.
• Salesforce as Service Provider and Identity Provider for SSO
  Depending on your authentication needs, you can create an identity provider chain, configure SAML single sign-on (SSO) across multiple orgs or Experience Cloud sites, or use the predefined Salesforce authentication provider. If you want users to log in to Salesforce from a third-party identity provider and immediately have access to a client app, set up an identity provider chain. If you want users to access several orgs or sites with one set of credentials, set up SAML SSO between multiple orgs or sites. You can also set up SSO between two orgs with the Salesforce authentication provider, which authenticates users and authorizes access to protected data.
• Single Sign-On for Portals and Sites
  You can configure single sign-on (SSO) for portals and Sites. Keep in mind that customer and partner portals aren't available for new orgs as of the Summer ’13 release. Use Experience Cloud sites instead.
• Single Sign-On Examples
  You can configure Salesforce to play several different roles in the single sign-on (SSO) process. This section includes examples of how to configure Salesforce and some third-party applications for SSO.
• Single Logout
  With single logout (SLO), users can log out from the identity provider and the service provider by logging out from either of them. Whether Salesforce is the service provider or identity provider, you can enable SLO with SAML or OpenID Connect. SLO can increase security and save users time by removing manual logout from every individual application.
• Delegated Authentication
  Delegated authentication is similar to single sign-on (SSO), but it offers a slightly different experience to users. With delegated authentication, one system relies on another system to validate user credentials. For example, you can configure your Salesforce org to rely on a Lightweight Directory Access Protocol (LDAP) server to validate credentials. Both SSO and delegated authentication enable users to log in to multiple apps with one set of credentials. However, with delegated authentication, users must log in to each app separately.