Salesforce SSO (single sign-on) lets people log in to Salesforce once, through an identity provider they already use, instead of keeping a separate Salesforce password. There are two main forms: SAML single sign-on, where a corporate identity provider such as Okta, Microsoft Entra ID or Google vouches for employees, and social sign-on, where customers or partners log in with an account such as Google, Facebook or PayPal. Both need My Domain.
This guide was first published in 2022 as a walkthrough of social sign-on with PayPal. It has been rewritten for 2026 to cover Salesforce SSO as a whole: both setups step by step, the MFA rule for SSO users, and the mistakes that cause failed logins.
What is SSO in Salesforce?
SSO in Salesforce means another system proves who the user is, and Salesforce trusts it. Trailhead defines single sign-on as letting users "access all authorized resources without logging in separately to each one", and social sign-on as users logging in to a Salesforce org with their credentials from an external authentication provider such as Facebook, LinkedIn or Google (Trailhead: Salesforce Identity Features). The same unit notes that Salesforce requires a My Domain for both.
Two roles appear in every SSO setup. The identity provider (IdP) authenticates the user. The service provider trusts the IdP and lets the user in. When employees log in to Salesforce through Okta or Entra ID, Salesforce is the service provider. Salesforce can also act as the identity provider for other apps, but that is a separate setup.
SAML SSO vs social sign-on
SAML SSO is for employees through a corporate identity provider; social sign-on is for customers and partners through accounts such as Google or PayPal.
| SAML single sign-on | Social sign-on | |
|---|---|---|
| Typical users | Employees and contractors | Customers and partners on an Experience Cloud site |
| Identity provider | Corporate IdP (Okta, Microsoft Entra ID, Google Workspace, ADFS and others) | Google, Facebook, Amazon, PayPal or any OpenID Connect provider |
| Protocol | SAML 2.0 | OAuth 2.0 and OpenID Connect |
| Where you set it up | Setup → Single Sign-On Settings | Setup → Auth. Providers |
| How users are matched | Federation ID on the user record | A registration handler that finds or creates the user |
| Can it create users? | Optional, with just-in-time provisioning | Yes, through the registration handler |
How to set up SAML single sign-on in Salesforce
You give each user a Federation ID, enable SAML, create a SAML configuration from the IdP's details, then give the IdP Salesforce's login URL. These steps follow Trailhead's inbound SSO guide. Do them in a sandbox first.
- Confirm My Domain. Note your My Domain URL from the My Domain Setup page; it becomes the Entity ID.
- Give each user a Federation ID. In Setup → Users, edit the user and enter the Federation ID under Single Sign On Information. It must be unique for each user in the org and match the identifier your IdP sends.
- Enable SAML. In Setup → Single Sign-On Settings, click Edit, select SAML Enabled and save.
- Create the SAML configuration. Click New and enter the IdP's Issuer, upload the Identity Provider Certificate, set SAML Identity Type to "Assertion contains the Federation ID from the User object", choose where the identity sits in the assertion, and set the Entity ID to your My Domain URL.
- Configure the IdP. After saving, copy the Login URL from the Endpoints section and enter it in the IdP as the recipient (ACS) URL, together with the Entity ID.
- Test. Log in through the IdP with a test user and check you land in Salesforce as the user with the matching Federation ID.
- Add the button to the login page. In the Authentication Configuration section of My Domain, add the SAML configuration as a login option, and decide whether users may still log in with a password.
SP-initiated and IdP-initiated login
Test both directions. IdP-initiated login starts in the identity provider's app portal, which sends the user to Salesforce with an assertion; Trailhead's test follows this route. SP-initiated login starts at your My Domain login page or a Salesforce link: Salesforce sends a request to the IdP (the configuration's Service Provider Initiated Request Binding setting controls how) and the user comes back signed in. Bookmarks and links in emails use the SP-initiated route, so it is the one users hit most.
Creating users automatically with just-in-time provisioning
To create or update users from the assertion, edit the SAML configuration and select User Provisioning Enabled. Salesforce Help's JIT article says this needs the Federation ID identity type, and with standard provisioning the assertion must carry at least Email, LastName, ProfileId and, for new users, Username. If no user has the Federation ID sent, Salesforce creates one. Decide which profile and permission sets JIT users get before you turn it on; our guide to profiles in Salesforce helps.
How to set up social sign-on (including PayPal)
Social sign-on is set up with an authentication provider (Auth. Provider) and a registration handler. Trailhead's social sign-on unit uses Facebook as its example; the steps are the same for other providers:
- Create an app with the provider (for example in the Facebook, Google or PayPal developer console) and note its client ID and secret. Trailhead advises always using your own app in production rather than Salesforce's test values.
- Create the Auth. Provider. In Setup → Auth. Providers, click New, choose the provider type, and enter the consumer key and secret from your app.
- Set the registration handler. Choose Apex and let Salesforce create a template, or use a sample handler. The handler decides whether to match an existing user or create a new one.
- Choose Execute Registration As. Use a dedicated integration or service user, not a person's account, so logins don't break when that person leaves.
- Test with the Test-Only Initialization URL.
- Add it to the login page. For an Experience Cloud site, open the site's Workspaces → Administration → Login & Registration, select the provider and save.
If PayPal is not in your org's list of provider types, use OpenID Connect: PayPal states that Log in with PayPal "uses OAuth 2.0 and OpenID Connect", and Trailhead notes that providers can be added through OpenID Connect. Choose the OpenID Connect provider type and enter PayPal's authorise, token and user-info endpoints from its developer documentation. Request only the scopes you need, starting with openid and email.
Does SSO replace MFA?
No. As of November 2026, SSO users still need MFA, either from the identity provider or from Salesforce. According to Salesforce's MFA page, the MFA requirement went into effect on 1 February 2022, and if you use SSO you must still make sure MFA is enabled for all Salesforce users. You can use your SSO provider's MFA service, or, for Salesforce Platform products, Salesforce's free built-in MFA. In practice, most companies enforce MFA in their IdP so users verify once. Remember users who can still log in directly with a password, such as administrators kept as a break-glass account: they need Salesforce MFA.
Common Salesforce SSO mistakes
Most failed SSO logins come from identifiers, certificates or URLs that don't match.
- Federation ID mismatch. The most common failure. The value the IdP sends must match the user's Federation ID exactly; check Login History after a failed login to see whether the assertion or the Salesforce configuration is at fault. With JIT on, Salesforce returns an error code in the URL, for example for a missing or mismatched Federation ID.
- Expired certificates. IdP signing certificates expire. Put the renewal date in a calendar and update Salesforce before it lapses.
- Locking everyone out. Keep at least one administrator able to log in without SSO before you disable password logins.
- Changing My Domain. A new My Domain name changes the login URL and Entity ID, so the IdP configuration must be updated at the same time.
- Personal account as the registration user. Social sign-on fails when that user is deactivated.
- Treating SSO as the whole security model. SSO controls who gets in, not what they can see; see our Salesforce security guide for permissions and sharing.
- Forgetting sandboxes. A sandbox has its own My Domain URL and needs its own SSO configuration in the IdP; our sandbox guide explains why refreshed sandboxes need checking.
Getting help
Identity is one of the few changes where a mistake can lock out a whole company. Techila is a Salesforce Summit Partner; our integration team sets up SAML SSO with corporate identity providers and social sign-on for Experience Cloud sites, and tests both in a sandbox first. Talk to us about your login setup.
Frequently asked questions
What is SSO in Salesforce?
Single sign-on lets users reach Salesforce and their other authorised apps after signing in once. Salesforce can trust an external identity provider through SAML, or let users log in with an external account such as Google or Facebook through an authentication provider, known as social sign-on.
Do I need My Domain for Salesforce SSO?
Yes. Trailhead states that Salesforce requires a My Domain for single sign-on and social sign-on. In SAML setup, the Entity ID is your My Domain URL.
What is a Federation ID in Salesforce?
It is the field on the user record that links a Salesforce user to their account in the identity provider. The SAML assertion carries the Federation ID, and it must be unique for each user in the org.
Does SSO replace MFA in Salesforce?
No. Salesforce's MFA requirement, in effect since 1 February 2022, also covers users who log in through SSO. You can satisfy it with your identity provider's MFA, or for Salesforce Platform products with Salesforce's own free MFA.
Can users log in to Salesforce with PayPal?
Yes, through an authentication provider. PayPal says Log in with PayPal uses OAuth 2.0 and OpenID Connect, and Salesforce lets you add providers through OpenID Connect, so PayPal can be configured like other social sign-on providers, typically for an Experience Cloud site.