Single Sign-On Settings
Single Sign-On Settings is the Setup page in Salesforce where admins configure SAML and OpenID Connect (OIDC) integrations that let users log into Salesforce with credentials from an external identity provider (Okta, Azure AD, Google, OneLogin, ADFS, others).
Definition
Single Sign-On Settings is the Setup page in Salesforce where admins configure SAML and OpenID Connect (OIDC) integrations that let users log into Salesforce with credentials from an external identity provider (Okta, Azure AD, Google, OneLogin, ADFS, others). The page lets the admin upload the identity provider's certificate, define the SAML attribute mapping, set the entity ID and login URL, and turn SSO into the primary or only login path for the org. Once configured, users land in Salesforce already authenticated, with their identity verified by the external provider.
Single Sign-On Settings is the bridge between Salesforce and the enterprise identity stack. Most large organizations centralize authentication in an external identity provider for compliance, user lifecycle management, and security policy enforcement. SSO Settings lets Salesforce participate in that central identity model. Beyond convenience, SSO is the prerequisite for many enterprise policies: forced MFA at the IdP level, conditional access based on device posture, automated deactivation when users leave the company. The Salesforce login screen becomes a portal to the IdP, not a standalone credential gate.
How Single Sign-On Settings integrates Salesforce with enterprise identity
SAML and OIDC: the two protocol options
Salesforce supports two SSO protocols. SAML (Security Assertion Markup Language) is the enterprise-friendly XML-based protocol used by most identity providers (Okta, Azure AD, ADFS, OneLogin). OIDC (OpenID Connect) is the newer JSON-based protocol layered on OAuth 2.0, used by Google, Apple, and modern API-friendly providers. Both protocols achieve the same goal (federated identity), but the configuration paths differ. SAML requires certificate exchange and attribute mapping. OIDC requires Client ID, Client Secret, and discovery URL configuration. Most enterprise deployments use SAML; consumer-facing deployments often use OIDC.
SP-initiated vs IdP-initiated SSO flows
Two SSO flows exist. Service Provider (SP)-initiated SSO starts at Salesforce: the user navigates to the Salesforce login page, picks SSO, and is redirected to the IdP for authentication. IdP-initiated SSO starts at the IdP: the user logs into Okta or Azure AD, clicks the Salesforce tile, and lands in Salesforce already authenticated. Both flows are supported in Single Sign-On Settings. SP-initiated is more common in environments where users bookmark Salesforce URLs directly. IdP-initiated is the cleaner experience when the IdP is the primary entry point.
Just-in-Time (JIT) user provisioning
With JIT enabled, the first SSO login from a new user automatically creates the Salesforce user record. The SAML attributes from the IdP populate the User fields (Username, Email, FirstName, LastName, ProfileId, etc.). JIT eliminates the need to pre-provision users in Salesforce manually. The trade-off is that the SAML attributes must be configured correctly on the IdP side; missing or malformed attributes break the JIT creation. JIT is typically used alongside the IdP's user lifecycle management for automated user creation and deactivation.
My Domain prerequisite
Salesforce requires a configured My Domain before SSO can be enabled. My Domain replaces the default login.salesforce.com URL with a custom subdomain like yourcompany.my.salesforce.com. The SSO flow needs this custom URL to construct the SAML assertion and respond URLs correctly. Configuring My Domain is the first step in any SSO rollout. Salesforce has been making My Domain mandatory for all orgs over time, so this prerequisite is becoming less of a barrier.
Federation ID and the user mapping
Each Salesforce user has a Federation ID field that maps to the external identity. The IdP includes the Federation ID in the SAML assertion (typically as the NameID or a custom attribute). Salesforce uses the Federation ID to look up the matching user record. The Federation ID is typically the user's email or a stable internal identifier (employee ID). Changing the Federation ID breaks the SSO mapping for that user; treat it as immutable once set. Most modern SSO setups use the email address as the Federation ID for simplicity.
Multiple SSO configurations and login policies
An org can have multiple SAML SSO configurations active simultaneously: one for employees through Azure AD, one for partners through a different IdP, one for customers through a third. Each configuration is a separate SAML Settings record in Setup. The org also has a Login Policy: whether the Salesforce login page allows username-password login, SSO-only, or both. SSO-only policy forces every user through the IdP, eliminating local password risk. Mixed-mode policy lets admins use local username-password while users use SSO; this is the safer default during rollout.
Identity Provider role: Salesforce as the IdP
Beyond consuming SSO, Salesforce can itself act as an Identity Provider. Setup, Identity Provider, Enable. Other applications (third-party SaaS, custom apps) can then SSO into Salesforce as the IdP. This is less common than the Salesforce-as-SP role but useful for organizations that want Salesforce to be the central identity gateway. Configuration is symmetric: certificate exchange, attribute mapping, entity ID. Most enterprise deployments use a dedicated IdP (Okta, Azure AD) rather than Salesforce-as-IdP, but the option exists.
Setting up Single Sign-On in Salesforce
Configuring SSO is a multi-step process: prepare My Domain, gather IdP metadata, create the SAML Settings record, configure the IdP side, test the flow, decide on login policy.
- Configure My Domain first
Setup, My Domain. Pick a custom subdomain. Wait for the deployment to complete (typically 24-48 hours). Without My Domain, SSO cannot be configured.
- Gather IdP metadata
From the IdP (Okta, Azure AD), download the SAML metadata XML or copy the entity ID, login URL, and signing certificate.
- Create the SAML Settings record
Setup, Single Sign-On Settings, New from Metadata File or New manual. Upload the IdP metadata or paste the values. Save.
- Configure the SP side on the IdP
Back on the IdP, configure Salesforce as a service provider. Use the Salesforce metadata (entity ID = your My Domain URL, ACS URL = the My Domain SAML endpoint).
- Configure attribute mapping and Federation ID
On the IdP side, configure SAML attributes to include the user's Federation ID (typically email). On the Salesforce side, populate the Federation ID field on each user.
- Test the SSO flow
Use SP-initiated flow: navigate to the My Domain login URL, click the SSO button, complete the IdP login, confirm landing in Salesforce.
- Enable Just-in-Time provisioning if needed
For auto-creation of new users, enable JIT in SSO Settings and configure the SAML attributes for User fields (Username, Email, Profile, etc.).
- Set the Login Policy
Setup, My Domain, Authentication Configuration. Decide whether to require SSO (SSO-only) or allow both. Start with both during rollout; transition to SSO-only after stabilization.
The configuration record per IdP, holding entity ID, login URL, certificate, and attribute mapping.
The user field that maps to the external identity assertion from the IdP.
Automatic user creation on first SSO login, populating User fields from SAML attributes.
The custom subdomain required for SSO. Prerequisite for the entire feature.
Org-level setting that allows password-only, SSO-only, or mixed-mode authentication.
The reverse mode where Salesforce acts as the IdP for other applications, less common than the SP role.
- My Domain must be configured before SSO. Without it, the SAML configuration cannot be created. Plan for the 24-48 hour My Domain deployment.
- Certificate rotation on the IdP side breaks SSO until the new certificate is uploaded in Salesforce. Track certificate expiration dates carefully; automate the renewal if possible.
- Federation ID mismatches between Salesforce users and IdP user identities cause login failures. Audit the mapping during rollout.
- SSO-only policy locks out all non-SSO logins, including admins. Keep a break-glass admin account that bypasses SSO for emergency access.
- JIT provisioning relies on correct SAML attribute configuration on the IdP. Missing or malformed attributes break user creation, leaving the user with no Salesforce account.
Trust & references
Straight from the source - Salesforce's reference material on Single Sign-On Settings.
- Single Sign-On OverviewSalesforce Help
- SAML Single Sign-OnSalesforce Help
- Just-in-Time ProvisioningSalesforce Help
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What are SSO Settings?
Q2. Why use SSO?
Q3. What Identity Providers work?
Discussion
Loading discussion…