Identity Provider
An Identity Provider is the role in a Single Sign-On relationship that authenticates the user and asserts their identity to other applications.
Definition
An Identity Provider is the role in a Single Sign-On relationship that authenticates the user and asserts their identity to other applications. In Salesforce terms, the platform can act as either an Identity Provider (it authenticates users for external applications) or a Service Provider (it accepts identity assertions from an external IdP like Okta, Microsoft Entra, Google Workspace, or Ping Identity). Most enterprise Salesforce deployments configure an external IdP for workforce SSO so users log in once and access Salesforce alongside Slack, Workday, and other SaaS apps.
The standards behind Identity Provider relationships are SAML 2.0 (the older XML-based protocol) and OpenID Connect / OAuth 2.0 (the modern JSON-based protocol). Salesforce supports both as IdP and as SP. SAML dominates legacy enterprise SSO; OIDC dominates new integrations and consumer-facing identity. Configuring an Identity Provider connection involves exchanging certificates, configuring entity IDs, mapping user attributes from the IdP to Salesforce User fields, and testing the handshake. Done correctly, users see seamless SSO; done incorrectly, users hit cryptic authentication errors that look mysterious to debug.
How Identity Providers shape Salesforce authentication
Salesforce as Service Provider versus Identity Provider
Most enterprise deployments configure Salesforce as the Service Provider, with an external IdP (Okta, Microsoft Entra, Ping) handling authentication. Users authenticate to the IdP, and the IdP asserts the identity to Salesforce via SAML or OIDC. Salesforce can also act as the IdP for other applications, which is common for Experience Cloud customer portals where customers authenticate to Salesforce and then SSO into related partner sites. The role choice depends on who owns the user directory: enterprise IT for workforce, Salesforce for customer identity.
SAML 2.0: the legacy enterprise standard
SAML 2.0 has been the dominant enterprise SSO protocol since 2005. The IdP issues an XML-based SAML assertion signed with the IdP''s certificate. Salesforce as Service Provider validates the signature, extracts user attributes, and creates a Salesforce session for the user. The configuration involves Federated ID (the user identifier shared between IdP and Salesforce), entity IDs, certificates, and attribute mappings. SAML is verbose but battle-tested; most enterprise IdPs ship pre-built integration templates for Salesforce that handle the configuration nuance.
OpenID Connect: the modern alternative
OpenID Connect (OIDC) is the identity layer on top of OAuth 2.0. The IdP issues an id_token (a JSON Web Token containing user claims) alongside the OAuth access token. Salesforce as Service Provider validates the JWT signature and creates a session based on the claims. OIDC is lighter weight than SAML, easier to debug (JSON not XML), and the modern direction for new integrations. New Salesforce SSO deployments should default to OIDC unless the IdP only supports SAML.
Just-in-Time provisioning and SCIM
Two patterns handle user provisioning. Just-in-Time (JIT) provisioning creates the Salesforce user automatically on first SSO login, using attributes from the SAML assertion or OIDC claims. Profile assignment, role, and other fields populate from the IdP. SCIM (System for Cross-domain Identity Management) is the more sophisticated pattern: the IdP pushes user lifecycle events (creation, updates, deactivation) to Salesforce via a SCIM API, keeping the directories in sync proactively. JIT is simpler; SCIM is more thorough.
Identity Provider sessions and deep linking
Once a user has an IdP session, returning to Salesforce reuses it. SP-initiated SSO starts with the user navigating to Salesforce; the SP redirects to the IdP, which authenticates and redirects back. IdP-initiated SSO starts with the user logging into the IdP portal and clicking a Salesforce tile; the IdP sends the assertion directly. Deep linking lets the IdP-initiated flow land on a specific Salesforce page rather than the home screen. Both flows need explicit configuration on both sides.
MFA enforcement and IdP responsibilities
Salesforce requires multi-factor authentication for direct logins as of 2022. When SSO is configured, MFA enforcement moves to the IdP: Salesforce trusts the IdP to enforce MFA, and the IdP becomes the place where MFA policy is configured. This shift is the architectural reason SSO matters: the IdP becomes the central point for MFA, password rotation, conditional access, and identity governance, while Salesforce focuses on application authorization. Configure the IdP for the right MFA policy and Salesforce trusts the assertion.
Common integration challenges
Certificate expiration is the most common SSO failure pattern. The IdP certificate expires, the SAML signature fails to validate, and users cannot log in. Monitor certificate expiration dates on both sides and rotate proactively. Other common issues: attribute mapping mismatches (the IdP sends an attribute Salesforce does not expect), entity ID mismatches (SP and IdP disagree on the expected identifier), and session timeout misalignment between the IdP and Salesforce. Test thoroughly before going live and after every IdP configuration change.
How to configure Identity Provider SSO with Salesforce
Configuring SSO between Salesforce and an Identity Provider has two sides: the IdP side and the Salesforce side. Both need certificates, identifiers, and attribute mappings configured to match. Use the IdP''s Salesforce integration template if available; build manually only if the template does not exist or the configuration requires customization.
- Decide between SAML and OpenID Connect
SAML for legacy enterprise IdPs that do not support OIDC. OIDC for new integrations with modern IdPs. Both work; OIDC is easier to debug and lighter to operate. Confirm with the IdP team which protocols they support.
- Designate the Federated ID field
Pick which field on the Salesforce User identifies the user to the IdP. Username, Federation Identifier, or a custom field. The IdP must assert the matching value in the SAML NameID or OIDC sub claim.
- Enable My Domain and configure SSO Settings
Salesforce SSO requires My Domain. Setup > My Domain > activate. Then Setup > Single Sign-On Settings > New. Upload the IdP certificate, enter the IdP entity ID, configure attribute mappings.
- Configure the Salesforce app on the IdP
On the IdP side (Okta, Entra, Ping), create a new Salesforce application. Most IdPs provide a template. Configure the ACS URL (Salesforce SAML endpoint), entity ID, and signing certificate.
- Configure attribute mappings
Map IdP user attributes to Salesforce user fields. Common mappings: email, first name, last name, role/profile. JIT provisioning needs more mappings; SCIM handles them through the SCIM API instead.
- Test SP-initiated SSO
Navigate to your Salesforce My Domain URL. The login screen should show the SSO button or auto-redirect to the IdP. Authenticate with IdP credentials. Confirm successful redirect back into Salesforce with the right user identity.
- Test IdP-initiated SSO
From the IdP user portal, click the Salesforce tile. Confirm the user lands in Salesforce with the right identity. If deep linking is configured, confirm the user lands on the intended page.
- Set up certificate expiration monitoring
Build alerts for upcoming certificate expirations on both sides. Salesforce sends warning emails 90, 60, and 30 days before expiration. The IdP typically has its own monitoring. Both sides need to rotate before the certificate expires or SSO breaks.
SAML for legacy enterprise IdPs. OIDC for modern integrations. Both supported by Salesforce as IdP and SP.
The Salesforce User field that identifies the user to the IdP. Username, Federation Identifier, or a custom field.
JIT creates users on first SSO login; SCIM proactively syncs user lifecycle from the IdP. Pick based on directory governance needs.
- Certificate expiration is the leading cause of SSO outages. Monitor expiration dates on both sides and rotate well before expiration.
- Salesforce requires My Domain for SSO. Without My Domain enabled, SSO configuration cannot be activated. Enable My Domain before starting the SSO setup.
- Attribute mapping mismatches produce cryptic errors. The IdP sends an attribute that Salesforce does not expect, or the case differs. Confirm the exact attribute names and values during initial testing.
- MFA enforcement moves to the IdP when SSO is configured. The IdP becomes responsible for MFA; Salesforce trusts the assertion. Configure the IdP MFA policy carefully because Salesforce trusts whatever the IdP asserts.
- JIT provisioning creates users on first SSO login. If the IdP misassigns profile or role attributes, new users land with wrong permissions. Audit JIT provisioning logs for unexpected user creation.
Trust & references
Cross-checked against the following references.
- Salesforce as Identity ProviderSalesforce Help
- Single Sign-On OverviewSalesforce Help
- SAML SSO with SalesforceSalesforce Help
Straight from the source - Salesforce's reference material on Identity Provider.
- Single Sign-OnSalesforce Help
- Identity Provider ExamplesSalesforce Help
- Just-in-Time ProvisioningSalesforce Help
Hands-on resources to go deeper on Identity Provider.
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. Can a Salesforce admin configure Identity Provider without writing code?
Q2. Why is understanding Identity Provider important for Salesforce admins?
Q3. What is the primary benefit of Identity Provider for Salesforce administrators?
Discussion
Loading discussion…