Salesforce Single Sign On Flows

Single Sign On (SSO) flows enable users to authenticate using their identity from an external system. There are three mechanisms which can be used to achieve this in Salesforce:

  • SAML, where signed structured messages known as SAML requests and assertions are passed between the identity provider and service provider via the browser.
  • OpenID Connect, which leverages OAuth web server or user agent flows to establish trust.
  • Delegated Authentication, a mechanism based on capturing and submitting credentials for authentication via a SOAP message. Can be useful for authenticating to systems which don't offer other protocols.

This section outlines the sequence of messages in SSO mechanisms supported by Salesforce for the flows below:

Service Provider (SP) Initiated SSO

SP Initiated SSO Diagram

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

OpenID Connect (OIDC)

OpenID Connect SSO Diagram
  • 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:
  • 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