The Short Answer
Salesforce identity architecture isn't a one-time technical project; it's a daily control layer that governs who logs in, with what identity, which permissions they hold, and what happens when they should no longer have access. The choice between SAML and OIDC, JIT and SCIM, and between IdP-level MFA policies and internal Salesforce enforcement—these may seem like minor configuration details. In reality, they determine how long it takes to block access for a terminated employee and what percentage of such incidents will only be discovered during an audit.
The correct approach doesn't start with the protocol, but with two fundamental questions: Who is the single source of truth for user identity, and what is the maximum permissible time between an offboarding event and the actual blocking of access? All other decisions—federation type, provisioning method, session policy, and the Break Glass process—stem from these answers.
Organizations also grappling with permission-related questions, not just authentication, can find more information in the Salesforce Permission Model.
Decision Map: Four Layers of Identity in Salesforce
| Layer | Key Question to Decide | Main Options | What Breaks If Decided Incorrectly |
|---|---|---|---|
| Federation and Authentication | Who is the Identity Provider and how does Salesforce trust it? | SAML 2.0, OIDC, Delegated Authentication | Dual login, attribute mismatch, trust breach |
| Provisioning and Lifecycle | How is a user created, updated, and deactivated? | JIT Provisioning, SCIM, Manual Creation | Orphaned accounts, lingering access after departure |
| Session and MFA | Where are authentication strength and session duration enforced? | IdP MFA, Internal Salesforce MFA, Session Policies | MFA bypass via alternative path, perpetually active session |
| Break Glass and Audit | What happens when SSO fails, and who audits exceptions? | Controlled emergency user, Login History, Event Monitoring | Absolute reliance on IdP, inability to investigate retrospectively |
SAML vs. OIDC: Not a Question of "What's Newer"
The choice between these two protocols should not be driven by trends but by existing infrastructure. SAML operates with XML and signed assertions, commonly found in organizations with Active Directory Federation Services or a legacy IdP already serving dozens of other systems. OIDC, built on OAuth 2.0, is lighter to maintain and particularly convenient when the same IdP needs to serve modern API consumers alongside user logins.
A common mistake is choosing based on what seems "advanced" without verifying which attributes the existing IdP already sends and how they map to Salesforce (Username, Federation ID, Profile, Permission Set Group). Incorrect attribute mapping during setup often leads to manual correction of dozens of users in production, rather than just a configuration change.
A forgotten point: even when choosing OIDC or SAML, it's advisable to plan IdP-initiated versus SP-initiated login separately. Many common security incidents arise because SP-initiated access remains open, even though all login processes were designed to go through the IdP portal exclusively.
JIT Provisioning vs. SCIM: When "Just-in-Time" Isn't Enough
JIT (Just-In-Time) Provisioning creates or updates the user in Salesforce upon their first login, based on data received from the IdP in a SAML Assertion or OIDC Token. This is convenient, inexpensive to implement, and sufficient for most organizations where users log in regularly.
The problem: JIT doesn't handle deprovisioning. If an employee is removed from the IdP but doesn't log in again, their user account remains active in Salesforce indefinitely because no event triggers an update. This is precisely where SCIM (System for Cross-domain Identity Management) comes in—it enables proactive synchronization from the IdP to Salesforce, including immediate deactivation when a user is removed at the source.
The practical rule: If an organization requires offboarding within hours rather than days—for contractors, temporary employees, or access to sensitive data—SCIM is not a nice-to-have but a compliance requirement. If employee turnover is slow and governance already includes quarterly access reviews, JIT alone might suffice, provided it's accompanied by a documented manual process for immediate blocking.
Provisioning planning should always be evaluated against the complexity of its surrounding automation—for example, when Flows running permission assignment logic are involved during user creation, where the comparison in Flow vs. Apex for where custom code is worthwhile becomes relevant.
MFA and Session Policy: Two Layers, Not One
A common mistake is to rely solely on MFA enforced by the Identity Provider and assume it covers all Salesforce login paths. In practice, as long as a user can log in directly via login.salesforce.com—such as an integration, API User, or an Admin with backup access—a separate MFA policy defined within Salesforce itself (Identity Verification, Session Security Levels) is required.
Alongside this, session policies determine easily overlooked details: Session Timeout, "Force logout on session timeout," Login IP Ranges, and mandatory High Assurance Session for sensitive operations (e.g., changing permissions or mass data export). An organization that configures strong MFA but leaves Session Timeout at the default two hours creates a window where a stolen computer retains active access long beyond what's reasonable.
Break Glass and Audit: When SSO Fails, Who Gets In
Complete reliance on an external IdP creates a single point of failure: If the IdP goes down or if there's a bug in the federation configuration, no one, including those who need to fix the issue, can log in. The common solution is a Break Glass user—a super-admin account with independent authentication (not reliant on SSO), a password managed in a vault, not a person's memory, and separate MFA.
It's important to distinguish: Break Glass is not a "convenient back door"—it's a controlled emergency mechanism. Its use must trigger an automated alert and be reviewed within one business day by someone other than the user who accessed it. Many organizations set up the user correctly but overlook ongoing oversight—the password remains unrotated, and its permissions are overly broad by default.
Organizational Scenario: Offboarding Failure at a Mid-sized Insurance Company
Consider an insurance company with approximately 600 employees, using Okta as its Identity Provider and a SAML configuration with Salesforce established about three years ago. Provisioning is entirely based on JIT: when a new employee logs in for the first time, a user is created with a Profile and Permission Set Group according to their Okta group membership.
In one instance, a service representative was terminated on a Friday afternoon. The IT team immediately deactivated them in Okta. In practice, because there was no SCIM mechanism or webhook to synchronize deactivation to Salesforce, their user remained active there—and because their session was already active from that morning and "Force logout on session timeout" was not configured, they continued to access the system even after termination, until someone noticed during a weekly access review on Monday.
The solution implemented was not a full transition to SCIM (which would have required a separate project and integration budget), but an immediate combination of three actions: enabling "Force logout on session timeout" for all sensitive profiles, shortening Session Timeout from 120 minutes to 30 minutes for customer-facing roles, and adding an automatic step to the organizational offboarding process that performs direct deactivation in Salesforce as an independent action, not just an indirect result of Okta deactivation. SCIM remained a target for the next quarter, with budget and approval already secured, but the most dangerous gap was closed within a week.
Common Risks and Prevention Actions
| Risk | How it Manifests | Prevention Action |
|---|---|---|
| Full reliance on JIT without deprovisioning | Terminated users remain active indefinitely | Add an independent Salesforce offboarding step, not dependent on sync |
| MFA only at IdP | Integration and Admin users bypass MFA via direct login | Internal Salesforce MFA policy for all user types |
| Overly long Session Timeout | Stolen computer or forgotten open session retains access for hours | Shorten Timeout and Force Logout for sensitive profiles |
| Break Glass without oversight | Emergency account usage goes undetected | Automatic alert and review within one business day for any usage |
| Incorrect IdP attribute mapping | User receives incorrect Profile or Role on first login | Thorough mapping validation in Sandbox environment before production change |
Checklist for Identity Architecture Setup or Review
- ☐ A single Identity Provider is defined as the source of truth, and what happens when it fails is known.
- ☐ Protocol (SAML or OIDC) is chosen based on existing infrastructure, not trends.
- ☐ Attribute mapping between the IdP and Profile/Permission Set Group is tested in Sandbox.
- ☐ A clear policy is defined: JIT only, or JIT combined with SCIM based on offboarding requirements.
- ☐ MFA is enforced within Salesforce, not just at the IdP.
- ☐ Session Timeout and Force Logout are configured according to profile sensitivity.
- ☐ A controlled Break Glass user exists, with separate MFA and a password in a vault.
- ☐ The offboarding process includes an independent step for deactivation in Salesforce.
- ☐ Login History and Event Monitoring are reviewed on a regular schedule.
- ☐ There is a periodic access review plan that doesn't solely rely on IT's memory.
How to Measure the Architecture's Effectiveness
The primary metric is not "Is SSO active?" but the response time between an event at the source of truth and a corresponding change in Salesforce: how much time passes between user removal in the IdP and actual deactivation. A complementary metric is the rate of logins performed via an unexpected path (direct login instead of through the IdP), which should approach zero except for documented Break Glass access. A third metric is the frequency of permission reviews against the actual state—not every organizational change comes through the IdP, so quarterly reviews remain essential even with fully automated provisioning.
For implementing or auditing identity architecture in an existing Salesforce environment, progress can be made through CRM Architecture Services. Organizations also examining connections to ERP and payroll systems as part of the overall identity picture will find complementary background in Connecting Salesforce to ERP and a broader architectural overview in the CRM Architecture Guide.
Summary
Salesforce identity architecture is built once but tested daily through isolated incidents—a departing employee, a session that forgets to close, an integration that bypasses MFA. Key choices (SAML vs. OIDC, JIT vs. SCIM, dual MFA, controlled Break Glass) should not be derived from the IdP's default settings but from the required response time to block access and the sensitivity level of the exposed information. An organization that plans this layer in advance, rather than discovering gaps during an audit or after a security incident, saves both remediation costs and reputational and regulatory risks.