Legacy & Special Scenarios

• This flow makes use of a Single Sign On (SSO) configuration in Salesforce for authentication rather than a connected app, which isn't required.
• In general, as part of an SSO configuration Salesforce will accept SAML assertions which:
  • Are signed by the Identity Provider (IDP)
  • Have the Recipient attribute in the SubjectConfirmationData element set to an org-specific Login URL or OAuth 2.0 Token Endpoint indicated on the SSO settings page
  • Have an AudienceRestriction element with an Audience element indicating the correct Salesforce Entity ID
• The restrictions above make this flow impractical for most circumstances, and either a JWT or SAML bearer flow would almost always be preferable for server-server integrations.
• Historically, the SAML Assertion flow has been used in the context that a client app authenticated by an IDP needs to then authenticate as the logged in user to Salesforce. In some circumstances the SAML assertion could be reused by the client app to directly authenticate to the Salesforce org in this way. For this to be possible, the assertion can be created by the IDP with multiple AudienceRestriction elements, however Salesforce appears to only support the presence of a single SubjectConfirmationData element, which must have a Salesforce login URL as Recipient, so suitability would depend on the implementation of SAML in the client application.

• Current recommendation from IETF is not to use this flow. A more secure alternative should be used in almost all scenarios (e.g. web server for user authentication or JWT bearer for server authentication)
• The only circumstances this should be considered is where there is complete trust between all systems and networks. An example use case would be a user entering a password in real time on an internally managed client application which doesn't support a browser-based identity flow

• The flow can be used in circumstances where a client secret can't be protected, for example in a mobile or desktop application, or client app running in a browser, such as a SPA
• Identity is based on the same-origin policy (redirect_uri must match one of the Callback URL values in connected app)
• The flow is sub-optimal from a security perspective in many scenarios, as tokens are transmitted in URL. This means they are accessible to the browser and stored in browser history, which is frequently synced across devices and susceptible to attack. It's advisable to ensure that access token validity is short and refresh tokens aren't used to reduce the risk of such attacks
• Prior to 2017, this flow was recommended as best practice for mobile and native applications, however the current recommendation is to implement the more secure Authorisation Code with PKCE flow described below in contexts where an out of band POST can be made
• The Salesforce "User-Agent" flow is an adaptation of the OAuth 2.0 Implicit Grant flow where Salesforce acts as the authorisation and resource servers. Some security counter-measures (e.g. tokens and sessions being returned in URL hash fragments rather than query string parameters) have been implemented to improve security. A connected app is needed to support this configuration
• Salesforce Mobile SDK implements the User-Agent flow, so apps developed through this framework (including Mobile Publisher apps) will authenticate in this way

• 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 acts as an IDP, this flow can be started by launching the "IdP-Initiated Login URL" shown in the policies for the connected app set up for the SP. To launch a specific resource, also include a RelayState parameter with the intended URL from the SP. This URL can also be used as the connected app's Start URL to start this flow when the connected app's icon is clicked from the App Launcher. If Start URL is simply set to a resource from the SP, clicking the App Launcher will redirect to this resource without initiating SSO directly
• 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