Salesforce Single Sign-On Setup: A Step-by-Step SAML Guide

To set up single sign-on in Salesforce, you configure your org as a SAML service provider and trust an external identity provider (IdP) to vouch for your users. In practice that means five things. Deploy a My Domain, collect the IdP’s login URL, issuer and certificate, enable SAML in Single Sign-On Settings, create a SAML configuration that matches those values, and test with a non-admin user before you change anything for everyone. This guide walks through each stage and the mistakes that cause most failed rollouts.

TL;DR

• Salesforce SSO runs on SAML, with Salesforce as the service provider and your identity provider issuing the login assertions.
• Most failures come from three causes: the wrong certificate, clock drift between the IdP and Salesforce, and attribute mapping errors in Just-in-Time (JIT) provisioning.
• Keep a way in: test with a regular user, leave one admin on username and password, and calendar the certificate expiry date.
• Pair SSO with strong multi-factor authentication, because SSO concentrates risk in one login.

What you are actually setting up

Single sign-on lets a person log in once and reach several systems. SAML is one of the standard ways to make that happen. NIST’s glossary describes SAML as an XML-based protocol for exchanging authentication and authorization information, and SSO as the access property that results. So “SSO versus SAML” is not an either-or: SSO is the outcome, SAML is the mechanism.

In Salesforce’s model there are two parties:

• Identity provider (IdP): the system that authenticates your employee. It might be your company directory or a dedicated identity service.
• Service provider (SP): Salesforce. It does not check a password. It checks a signed assertion from the IdP.

Salesforce’s documentation says SAML lets users sign in to a Salesforce org from a third-party identity provider, and it can also be used to create user accounts automatically. The setup is a trust exchange: each side gets the other’s metadata or certificate, so assertions can be verified.

Before you start: the prerequisites checklist

Skipping this part is the most common reason a two-hour job turns into a two-day one.

1. A My Domain. SAML login relies on your org’s own domain URL. Deploy it first and confirm users can reach it.
2. Admin access to both sides. You need a Salesforce System Administrator and someone who can create an application in your IdP.
3. Federation ID plan. Decide which user field the IdP will send to identify the person: the Salesforce username or a Federation ID. Email addresses are convenient but change when people change names, so many admins prefer an employee ID or a stable user principal name.
4. A test user with a standard profile, not an admin.
5. A break-glass admin. Keep at least one administrator able to log in with username and password until SSO is proven. Locking yourself out is a real risk.
6. Accurate clocks. Check that the IdP server’s time is synchronized, for reasons covered below.
7. A list of integrations. Mobile apps, API users and sandboxes may behave differently from browser logins.

Salesforce also publishes prerequisites for SAML service provider integration when the org plays the identity provider role instead, which is a different scenario from the one in this article.

Step-by-step: configure SAML SSO in Salesforce

The exact screens in your IdP vary, but the Salesforce half is the same everywhere.

Step 1: Gather the values from your identity provider

Create a SAML application for Salesforce in your IdP, or open the one that already exists. You will need these items from it:

• The Issuer (sometimes called the entity ID)
• The SAML login URL (the IdP’s single sign-on endpoint)
• An optional logout URL
• The signing certificate in PEM or CER format, or a metadata XML file that contains it

You will also have to give the IdP some Salesforce values, namely the entity ID, the ACS (assertion consumer service) URL and the login URL. Salesforce generates these after you save your configuration, so expect to go back and forth once.

Step 2: Enable SAML in Single Sign-On Settings

1. In Salesforce, click the gear icon and open Setup.
2. Type “Single Sign-On” in Quick Find and open Single Sign-On Settings.
3. Click Edit, check SAML Enabled, and save.

If the option is missing, the feature may not be available for your org type, and Salesforce support is the right place to ask.

Step 3: Create the SAML configuration

On the same page, create a new configuration, either from metadata or manually. Upload the IdP’s metadata file when you have one, because it fills in the issuer, login URL and certificate with fewer typos. Otherwise, enter them by hand.

The fields that matter most:

Step 4: Send the Salesforce values back to the IdP

After saving, Salesforce shows the endpoints: Login URL, Logout URL, OAuth 2.0 Token Endpoint, and the Entity ID. Copy the Entity ID and ACS URL into your IdP application’s SAML settings. Set the name ID format and the attribute that carries the Federation ID or username to match what you chose in Step 3.

Step 5: Assign users

In your IdP, assign the application to your pilot group. In Salesforce, confirm that each pilot user has a Federation ID or username matching what the IdP will send. If you are using JIT provisioning, see the section below.

Step 6: Test, then roll out

Use a private browser window, and try both flows:

• IdP-initiated: start from the IdP’s app dashboard and click the Salesforce tile.
• SP-initiated: go to your My Domain URL and choose the SSO option.

Once both work for the pilot users, add the SSO button to your login page through My Domain settings, expand to more groups, and only then consider making SSO the required method. Leave the break-glass admin alone until the end.

The certificate trap: IdP certificate vs. SP certificate

Salesforce’s own support content calls out a frequent source of confusion: the IdP certificate comes from your third-party provider and verifies assertions coming in, while the SP certificate is generated in Salesforce and is used for Salesforce-initiated requests. Mixing them up during setup is a classic root cause of authentication failures that never seem to go away.

A rule of thumb that holds up: whatever the IdP signs with goes into the “Identity Provider Certificate” field. Whatever Salesforce signs with is for the IdP to import, and only if you enabled signed requests.

Plan for expiry

Certificates expire, and an expired IdP certificate stops verification. Salesforce’s guidance on replacing an expired certificate notes that this blocks user access to the org. Typical IdP certificates last one to three years, and Salesforce’s help material says self-signed Salesforce certificates run one or two years, depending on key size.

Put the expiry date in a shared calendar with a reminder at least 30 days ahead, and name a person responsible, not a team alias. When the IdP rotates its certificate, upload the new one in Single Sign-On Settings before the old one stops signing, or coordinate a maintenance window with your break-glass admin ready.

Clock skew and other silent login killers

SAML assertions are time-limited. Salesforce’s troubleshooting article states that assertions have a five-minute validity window with a 30-second allowance for clock skew. If the IdP’s server time drifts past that, users see login errors while the configuration looks perfectly correct. Check NTP synchronization on any IdP you host yourself.

Other things to check when the login fails:

• Wrong login URL. Users bounce between the IdP and Salesforce, or land on an error page.
• Identity mismatch. The IdP sends an email address, but Salesforce expects the username or a Federation ID that differs.
• Inactive or frozen users. SSO does not override a deactivated Salesforce account.
• Marketing Cloud. It has its own SSO flow, and Salesforce notes it can be sensitive to changing IP addresses, so networks that cycle public IPs may see persistent SAML errors.

A SAML tracer browser extension helps enormously. Capture the assertion, then compare the issuer, audience, recipient and name ID against your Salesforce configuration, one field at a time.

Just-in-Time provisioning: handle with care

JIT provisioning creates a Salesforce user the first time someone signs in through SSO. According to Salesforce, it can reduce administrative workload, but it depends on correct mapping of SAML attributes such as email or username to Salesforce user fields. Bad mappings are a frequent cause of “user not created” and “permission denied” errors.

Before turning it on:

1. List the required fields for a Salesforce user: username, email, last name, alias, profile and so on.
2. Make sure the IdP sends every one of them as an attribute.
3. Decide how profile and role are assigned. A default that grants too much is worse than no automatic account at all.
4. Test with two users who should land in different profiles.

JIT creates accounts, but it is not a complete lifecycle tool. When someone leaves, the IdP will stop authenticating them, though the Salesforce user record remains until someone deactivates it, and a username and password login may still exist. Pair SSO with a deprovisioning process.

Perspective: SSO is only as strong as the login behind it

We see SSO projects treated as a convenience project, and that undersells the risk. When one identity unlocks Salesforce, email, file storage and finance tools, an attacker who gets that one login gets everything. Convenience is real, but so is concentration.

Our view is that three habits matter more than any single setting:

• Make the primary login phishing-resistant. A strong, unique password is the floor. Passwordless MFA and biometric authentication remove the password as the thing to steal.
• Keep non-SSO credentials under control. Break-glass admins, API users and service accounts still have passwords. Those need a vault, rotation and an owner.
• Watch for exposure. Credentials leaked elsewhere are tried against your systems. Dark web monitoring tells you before the attacker does.

This lines up with NIST’s federation guidance. NIST’s Digital Identity Guidelines, updated in July 2025, treat federation as something that needs careful management of authentication and assertions, and relying parties such as Salesforce must be able to trust that assertions are verified. Configure signature validation properly and do not turn it off to “get it working”.

An SSO rollout that ends with a working login but leaves old passwords, shared spreadsheets and unmanaged service accounts untouched has solved the smaller half of the problem.

— Mike

Adding a second layer inside Salesforce

SSO does not replace MFA, it moves where MFA happens. If your IdP enforces MFA, users satisfy it there. If a user logs in with a Salesforce username and password, Salesforce’s own requirement applies. Salesforce describes its Authenticator as a mobile app that satisfies the MFA requirement, and users can register it at first login or later through Advanced User Details in personal settings.

Two practical points. Have users install the app before they start registration, and have them set up a backup in the app at that moment, since Salesforce stresses that this prevents an admin ticket when a phone is lost or replaced.

For highly sensitive apps, Salesforce also documents forced authentication: adding a ForceAuthn parameter to the SAML request makes users who are already signed in re-enter credentials. That is a useful control for actions such as approving payments or exporting data. Note that Salesforce documents this for the scenario where its org acts as the identity provider, so confirm how your own configuration handles it before relying on it.

Where password management fits with SSO

Even a well-run SSO deployment leaves gaps: apps that do not support SAML, admin consoles with local logins, shared team credentials and the IdP account itself. A password manager covers those.

If you want one place to handle both, our LogMeOnce business plans include Teams at $4.00 per month per user and Business at $7.99 per month per user, with Enterprise available as a custom option. For individuals who manage their own accounts, the Professional, Ultimate and Family plans start at $2.50 per month, and our passwordless MFA page explains how to remove the password from the daily login. If you want to see what a rollout could save before you commit, try the password manager ROI calculator.

A rollout plan you can copy

Working in a sandbox first is cheap and removes most surprises. Salesforce certificates and endpoints will differ between sandbox and production, so do not copy values blindly when you move.

FAQ

How do I set up single sign-on in Salesforce?

Deploy My Domain, open Setup, go to Single Sign-On Settings, enable SAML and create a configuration with your identity provider’s issuer, login URL and certificate. Then copy Salesforce’s entity ID and ACS URL back into the IdP and assign users. Test with a non-admin account before you roll out widely.

What is the difference between SSO and SAML?

SSO is the result: one login that opens several systems. SAML is a standard, XML-based protocol that carries the proof of login between the identity provider and the application. SAML is one common way to deliver SSO, and other protocols such as OpenID Connect can too.

Is single sign-on enabled in Salesforce by default?

No. An admin has to turn on SAML in Single Sign-On Settings and create a configuration. Until then, users sign in with their Salesforce username and password, plus whichever MFA method applies.

Why does my Salesforce SSO login fail with a valid configuration?

Check three things first: whether the IdP certificate in Salesforce is the one the IdP actually signs with, whether the IdP’s clock is within the allowed skew, and whether the name ID matches the username or Federation ID in Salesforce. A SAML tracer shows which of these is wrong in minutes.

How do I add an account to Salesforce Authenticator?

Install the app, then choose the Salesforce Authenticator option at your next login, or connect it from Advanced User Details in your personal settings. Set up the backup account during registration so you can move to a new phone without an admin.

Sources

• SAML SSO with Salesforce as the Service Provider, Salesforce Help
• Replace an Expired Certificate in SSO Settings, Salesforce Help
• Complete Prerequisites for SAML Service Provider Integration, Salesforce Help
• Marketing Cloud Single Sign-On Implementation Overview, Salesforce Help
• How to Set Up Salesforce Authenticator for MFA, Salesforce Help
• Connect Multi-factor Authenticator to a User Account, Salesforce Help
• Security Assertion Markup Language Single Sign-On, NIST CSRC Glossary
• SP 800-63-4, Digital Identity Guidelines, NIST CSRC

Sadia Israr

Sadia, with her Master of Computer Applications, stands at the intersection of technology and communication. Her academic background has endowed her with a deep understanding of complex technical concepts, which she skillfully simplifies for diverse audiences. Sadia’s extensive experience in both technical realms and writing enables her to translate intricate technical ideas into clear, engaging, and accessible content.