Salesforce Single Sign On (SSO) Flows

Videos created for Apex Hours are linked from the article pages - click "Read More" against a section above to check whether a video is available.

Some guidelines for choosing between SSO flows are outlined in the video below, and the full set of video content around SSO is available on this page.

• Enables authentication to Salesforce without prompting for credentials
• Application must manage or be able to acquire the token, assertion or password
• A token or assertion is preferable to avoid sending corporate passwords to or from Salesforce
• If a token or assertion is used, this should be set as the password in the POST to the Salesforce login page

• Provides a method of using credentials for applications which don't offer SAML to login to Salesforce
• My domain is not required
• Delegated authentication SOAP endpoint must comply to specific WSDL (which can be downloaded from Salesforce)
• Password is not validated in SF and instead passed to authentication service for validation, so Salesforce password policy doesn't apply
• This flow requires delegated authentication endpoint to support processing passwords
• Delegated authentication can be enabled / disabled by an admin from Single Sign On Settings
• Permission "Is Single Sign-On Enabled" controls by user whether passwords are submitted to delegated authentication service

SAML migration trick: It can be useful to block certain users from logging in with username and password. By enabling delegated authentication and using the "Is Single Sign-On Enabled" permission, these users will be prevented from using their Salesforce password to login

• This flow is inherently less secure than the SP-initiated version, and is highly susceptible to Man-in-the-Middle and CSRF attacks (see links below). Careful consideration should be made before choosing to use IDP-Initiated SSO
• When Salesforce is acting as an IDP, clicking an SP's connected app icon in the App Launcher doesn't actually use this flow, but instead an SP-initiated version with Relay_State = Start URL is initiated
• IDP-Initiated SSO can be used as part of canvas app authentication by selecting "Identity Provider Initiated" as the canvas app's initiation method option. Unlike the "Service Provider Initiated" option, this has the advantage that the SAML response can be passed and the user authenticated without the need for the canvas app / service provider to first serve an un-authenticated login page, which may not permit embedding in an iframe (this applies to Salesforce's own standard login page, so this consideration is relevant to Salesforce -> Salesforce canvas apps)
• If Salesforce acts as the Service Provider, general setup considerations and capabilities described in the Service Provider Initiated SSO flow apply except the requirement for My Domain, which isn't necessary here

• OpenID Connect is the accepted standard and most popular mechanism for identity verification using the OAuth 2.0 framework. Salesforce allows OpenID Connect providers to be set up as authentication providers for Social Sign On with simple configuration
• Many identity services offer an identity verification mechanism based on OAuth 2.0 and similar to but not completely consistent with OpenID Connect. It's possible to set up custom authentication providers for services like these by extending the Auth.AuthProviderPluginClass class with custom logic to initiate authentication and retrieve user information (details in Salesforce documentation)
• OpenID Connect is offered by services such as Google and Microsoft, and is likely used in the pre-configured authentication providers available for these services
• Some popular OAuth-based identity services which don't comply entirely with the OpenID Connect spec are also pre-configured in Salesforce. Examples include:
  • Facebook (which offers Facebook Login)
  • Twitter (Login with Twitter)
  • LinkedIn (Member Authorization API and Profile API for user attributes)
  • GitHub (Allows retrieving a user's profile info after securing an access token)
• A Salesforce org can also act as the OpenID Connect Provider for other applications. In this instance, either the web server version (as shown) or another OAuth flow could be used for the authentication/authorisation
• In addition to Social Sign On, authentication providers in Salesforce can be used to authenticate content providers for Salesforce Files Connect (e.g. Google or Office 365)
• Client id and secret are managed by Salesforce for standard authentication providers (Facebook, Google etc), though these can be overridden in the org if required

General details around characteristics of OpenID Connect:

• Nonce if provided is included as an attribute in the ID token - this binds the token to a specific authorisation request and help protect against replay attacks possible through CSRF
• The UserInfo endpoint can be used to provide ID claims not included in the scope of the ID token, for example picture, email, website, locale, phone number etc
• The draft OpenID Connect Session Management spec recommends the RP to regularly verify the session is still active at the OP, although these checks aren't made in the current Salesforce Auth. Provider implementation
• The OpenID Connect Core spec includes details on implementation of this flow

If Salesforce acts as the Service Provider:

• Salesforce "Single-Sign On Settings" should be configured with values from the IDP
• Certificate from the IDP should be uploaded as the identity provider certificate in Salesforce. This is used for signature validation on incoming SAML responses
• Requests will be signed by Salesforce with the selected certificate, which can be validated by the IDP if necessary
• IDP-encrypted assertions are also supported, and decryption certificate uploaded and selected as Assertion Decryption Certificate
• SAML request bindings can be configured to be bound to HTTP Redirect or HTTP POST (determines whether initial SAML authentication request is GET or POST)
• Just In Time (JIT) user provisioning can be configured to enable automatic creation/update of users based on contents of incoming SAML assertions. Salesforce will attempt to match a user and will either update this record or create a new user in real time. Standard provisioning allows assertion attributes corresponding to standard field names to be used for matching and values for field contents, or custom logic can be defined in a class implementing the Auth.SamlJitHandler interface
• The IDP will need to be set up with the Authorisation Consumer Service (ACS) URL ("Salesforce Login URL") and Entity ID
• MyDomain required for SP-Initiated SSO, which enables deep linking (landing on requested URL) and OAuth with SAML

For Salesforce to act as the Identity Provider:

• Salesforce identity provider setup must be enabled, and a connected app set up for each service provider specifying the Authorisation Consumer Service (ACS) URL and service provider's Entity ID, as well as general SAML configuration, which can differ by service provider
• User profiles or permission sets must be added to connected app for accounts to be used for SSO identity
• Optionally, SAML request signatures for a service provider can be validated by uploading the SP's signing certificate
• SAML responses can be encrypted for additional security
• The connected app's Start URL is used as Relay State if the app's icon is clicked in the Salesforce app launcher