Salesforce single sign-on lets people reach Salesforce with the same identity they use for email and every other work app. Your identity provider checks who they are, applies MFA and sends Salesforce a signed answer over SAML or OpenID Connect. Done well, it closes the offboarding gap and removes another password. Done badly, it locks out admins. The work sits in four choices: protocol, provisioning, fallback access and integration users.
Why put Salesforce behind your identity provider?
Because the identity provider becomes the one place where access starts and stops. When HR ends someone's employment and IT disables their directory account, the Salesforce login stops working with it.
That offboarding point matters more than convenience. Former staff with a working Salesforce password are an easy gap to miss, especially where a business team, not IT, runs Salesforce. Single sign-on also lets you apply one MFA policy, one password policy and one set of conditional access rules everywhere. Users get one fewer password to forget, which cuts reset tickets.
It does not decide what people can see once they are in. Profiles, permission sets and the sharing model still do that, so SSO is a front door, not a floor plan.
Should we use SAML or OpenID Connect for the Salesforce login?
Either works, and Salesforce supports both as a service provider. Pick the one your identity provider handles best for Salesforce, which for most enterprise directories is SAML.
SAML is the long-established choice and has the widest support for Salesforce-specific features such as just-in-time provisioning from the assertion. OpenID Connect is configured in Salesforce as an authentication provider and suits identity platforms built around OAuth. Microsoft Entra ID, Okta and Google Workspace all offer Salesforce in their app catalogs, typically using SAML. Whichever you choose, you need My Domain, because SSO settings and the branded login page hang off your org's own domain. Every org now has My Domain, but check that bookmarks, integrations and email links use it rather than the generic login address.
What is the difference between IdP-initiated and SP-initiated login?
It is about where the user starts. IdP-initiated means clicking a Salesforce tile in your identity provider's portal; SP-initiated means going to your Salesforce domain first and being redirected to sign in.
Support both. SP-initiated login is what makes deep links work, such as a record link in an email or a Slack message. Without it, the user lands on a login page and loses the record they wanted. Test both paths, on desktop and in the Salesforce mobile app, before you call the setup done.
How does SSO satisfy Salesforce's MFA requirement?
Salesforce accepts MFA performed at your identity provider, so users do not need a second Salesforce prompt. The catch is that your provider must prove MFA happened in the response it sends.
Salesforce reads standard authentication signals for this: an authentication context value in SAML, or authentication method references in OpenID Connect. During early 2026, Salesforce began requiring device activation for SSO logins that arrive without a recognized strong signal. Users then see an extra verification step on unfamiliar devices or networks. Fix this at the source: confirm your identity provider enforces MFA for the Salesforce app and passes the signal. If it cannot, Salesforce lets you apply its own MFA to SSO logins instead. Salesforce is also moving privileged users toward phishing-resistant methods, so check what your provider sends for admins.
Just-in-time provisioning or SCIM: how should user accounts be created?
Just-in-time provisioning creates or updates a Salesforce user at login. SCIM lets your identity provider create, update and deactivate users through Salesforce's SCIM endpoints, without waiting for anyone to log in.
The difference shows up at offboarding. Just-in-time provisioning cannot deactivate anyone, because a departed person never logs in again. Their account blocks SSO entry, but it still holds a license and may still own records or scheduled jobs. Many teams stop there and forget the license count. SCIM-based provisioning, where your identity provider supports it for Salesforce, deactivates the user when the directory account is disabled. Salesforce deactivates rather than deletes users, which preserves record ownership history.
Neither option should assign broad access by default. Map identity provider groups to a minimal profile and specific permission sets, and keep sensitive permissions as a separate, approved assignment.
Who should keep a Salesforce password after SSO goes live?
A small number of administrators, deliberately chosen. Salesforce itself advises against removing password login from every admin, because someone must be able to fix SSO when it fails.
Once SSO works, you can stop most users from logging in with Salesforce credentials. Enable the setting to disable those logins, then grant the Is Single Sign-On Enabled permission to the users it should cover. My Domain also has options to prevent login from the generic login.salesforce.com address. Leave two named admin accounts outside the requirement. Give them phishing-resistant MFA, store the procedure for using them, and review their login history. Treat them as break-glass accounts, not daily logins.
Does SSO cover Experience Cloud users and customers?
Not automatically. Customers and partners usually sign in through the site's own login page, not your workforce directory.
Experience Cloud sites can accept social sign-on, a separate customer identity service or a partner's own provider. Each needs its own authentication setup on the site. Keep employee SSO and external identity as separate decisions, with separate owners. Our guide to planning an Experience Cloud portal covers audiences and licensing.
What about integrations and API users?
Single sign-on is for people. Integrations should authenticate with OAuth through an app definition in Salesforce, running as a dedicated integration user.
Do not route a middleware tool through an employee's SSO account. When that person leaves, the integration breaks, and their personal access was probably too broad anyway. For new integrations, Salesforce now steers customers toward External Client Apps instead of classic connected apps, so check the current guidance before you build. Existing connected apps keep working. The Salesforce Integration user license, with an API-only profile, is the usual home for these accounts. Request volumes are a separate question, covered in our guide to API limits.
Which session and login settings belong alongside SSO?
The ones that limit how long a session lasts and where it can come from. SSO makes the first login easy, so these settings control the risk after it.
- Session timeout: match it to your identity provider's session policy so users are not re-prompted at odd times.
- Login IP ranges: set on profiles where staff work from known networks, remembering that SSO users still pass this check.
- Login hours: useful for shift-based roles, but test carefully with anyone who works across time zones.
- Trusted IP ranges at the org level: these can reduce device activation prompts, so keep them narrow.
- Lock sessions to the IP address or domain where they started, if your policy calls for it.
Keep these minimal at first. Each restriction is another reason a valid user might fail to log in on launch day.
How do we monitor logins after go-live?
Start with Login History in Setup, which is included. It shows each attempt, the method used, where it came from and whether it succeeded.
Filter it after launch for failed SSO attempts, remaining password logins and logins from unexpected places. A steady trickle of password logins from regular users means the enforcement setting missed someone. Event Monitoring adds detailed login and API event logs, but most event types and longer retention need an add-on or Shield. Ask your Salesforce account team which event types your edition already covers. Your identity provider's own sign-in logs are often the richer source for workforce logins.
What should the testing and rollout plan include?
A sandbox rehearsal, a pilot group and a rollback you have actually tried. Never switch every user and every admin on the same day.
- Configure SSO in a full or partial sandbox first, using a test app in your identity provider.
- Load Federation IDs for every user and check them against the directory before go-live.
- Pilot with IT and one business team, covering desktop, mobile and deep links.
- Confirm the MFA signal arrives and device activation does not fire for normal logins.
- Roll out by group, then enable credential login blocking only after a quiet period.
- Write down how a break-glass admin turns SSO enforcement off, and rehearse it.
Which SSO decisions carry the most risk?
The ones that decide whether people can get in at all. Use this table to agree each decision before configuration starts.
| Decision | Options | Recommendation | Risk if wrong |
|---|---|---|---|
| Login protocol | SAML or OpenID Connect | Use what your identity provider supports best for Salesforce, usually SAML | Missing features or a fragile custom setup |
| Login start point | IdP-initiated, SP-initiated or both | Support both | Record links in email and chat stop working |
| MFA source | Identity provider or Salesforce MFA for SSO | Identity provider, with the signal verified | Extra prompts or device activation for every user |
| User provisioning | Manual, just-in-time or SCIM | SCIM where supported; just-in-time plus a deactivation process otherwise | Departed users keep active accounts and licenses |
| User matching | Federation ID or username | Federation ID from a stable directory attribute | Users land in the wrong account or cannot log in |
| Password fallback | Block for all or keep for named admins | Keep two break-glass admins with strong MFA | Nobody can log in during an SSO outage |
| Integration access | Employee login or dedicated integration user | Dedicated integration user with OAuth | Integrations fail when an employee leaves |
What mistakes do teams make with Salesforce SSO?
Most failures come from details that worked on day one and drifted later.
- Letting the signing certificate expire. Record the expiry date, assign an owner and rotate it in a sandbox first.
- Mismatched Federation IDs. A changed email address or name breaks the match unless you use an attribute that never changes.
- Blocking credential logins for every admin, then losing access when the identity provider has an outage.
- Relying on just-in-time provisioning and never deactivating anyone.
- Putting integrations behind a person's account instead of an integration user.
- Forgetting sandboxes. Each sandbox needs its own SSO settings after a refresh, or testers fall back to shared passwords.
If your org is overdue for a broader access review, our security review checklist covers permissions, sharing and audit beyond the login itself.
