Single Sign-On

💬 In plain words: Keep the three standards straight by separating identity from permissions. OAuth 2.0 handles authorization (what an application is allowed to do via APIs). OpenID Connect (OIDC) adds an identity layer directly on top of OAuth 2.0 (proving who the user is with a JSON id_token ). SAML 2.0 is the established XML standard for proving who a user is in enterprise networks. Single Sign-On (SSO) uses SAML or OIDC; API data access uses OAuth 2.0.

💬 In plain words: Delegated Authentication means Salesforce collects the username and password on its login screen (or through an API call), but asks your own external web service, "Are these credentials valid?" Because Salesforce makes a synchronous callout on every login attempt, you inherit complete responsibility for that endpoint's uptime and security. Always prefer federated authentication—such as SAML 2.0 or OpenID Connect (OIDC)—whenever possible, and treat Delegated Authentication strictly as a legacy bridge. 📌 Worked example: A manufacturing plant relies on a custom, 15-year-old LDAP directory that cannot issue SAML assertions or OIDC tokens, and security policy forbids storing corporate passwords inside Salesforce. By enabling Delegated Authentication, users type their credentials into Salesforce, and Salesforce sends an outbound SOAP request to a custom wrapper service in front of the factory's LDAP store. The wrapper returns true...

💬 In plain words: A SAML Single Sign-On (SSO) login works in up to three browser hops. The user starts either at a Salesforce URL (SP-initiated) or inside their company app portal (IdP-initiated). The Identity Provider authenticates the user and cryptographically signs an XML assertion stating, "This is Vinod, valid for 5 minutes." Salesforce verifies the signature against a stored certificate and opens a session. When a login fails, the Salesforce SAML Assertion Validator shows which verification step broke. 📌 Worked example: Asha clicks a bookmarked Salesforce Opportunity link (an SP-initiated flow). Salesforce generates a SAML Request and redirects her browser to Okta along with a RelayState parameter holding her Opportunity URL. Because she is already signed in to Okta, Okta immediately signs a SAML Response containing an assertion for Asha and posts it back to Salesforce. Salesforce validates the cryptographic signature, matches her FederationI...

💬 In plain words: Identity Connect is a synchronization bridge between Microsoft Active Directory (AD) and Salesforce. It watches AD and automatically mirrors joiners, movers, and leavers into Salesforce user records. When someone leaves the company and IT disables their AD account, their Salesforce access shuts off automatically without waiting for a manual ticket. 📌 Worked example: HR notifies IT that Ramesh is leaving the company, and an administrator disables his profile in Active Directory at 5:00 PM. Identity Connect detects the directory change and sets IsActive = false on his Salesforce user record minutes later. New joiners get provisioned from their AD security groups, and internal movers receive updated permission sets automatically. Active Directory holds the truth, and Salesforce mirrors it.

💬 In plain words: User provisioning spans a spectrum from creating records by hand, to pushing user updates ahead of time via a System for Cross-domain Identity Management (SCIM) or REST API integration, to Just-In-Time (JIT) provisioning . With JIT, nobody creates Salesforce users in advance: when a user logs in via Single Sign-On (SSO) for the first time, Salesforce reads the incoming SAML 2.0 assertion and creates or updates the User record on the spot. However, because JIT only runs during login, it never deactivates users when they leave—requiring a dedicated offboarding process. 📌 Illustrative Partner Onboarding Scenario: Suppose your company needs to onboard 5,000 external dealer portal users who already authenticate against their corporate Identity Provider (IdP). Instead of importing 5,000 CSV rows before launch, you enable SAML 2.0 JIT provisioning. When a dealer logs in for the first time, the SAML assertion passes their name, email, and dealer cod...

💬 In plain words: My Domain gives your Salesforce org its own dedicated subdomain and login URL—it is required for Lightning components and Single Sign-On (SSO). Multi-Factor Authentication (MFA) requires users to prove their identity with a second factor beyond a password and is mandatory for all human logins. Delegated Authentication is a legacy pattern where Salesforce forwards a user's plain-text password to your custom SOAP web service for validation—a high-maintenance approach largely replaced by SAML 2.0 and OpenID Connect. 📌 Illustrative Audit Scenario: When a compliance auditor asks, "How do you prove MFA is enforced across your org?", a well-designed architecture has a two-part answer. First, all workforce users log in through Single Sign-On, where the corporate Identity Provider (IdP) enforces MFA at the front door. Second, two emergency "break-glass" System Administrator accounts remain intentionally exempt from SSO so an...

💬 In plain words: Single Sign-On (SSO) lets users log in once with a trusted provider and enter connected applications without re-entering credentials. Security Assertion Markup Language (SAML 2.0) is an established XML-based standard commonly used for corporate workforce directories like Microsoft Entra ID or Okta. OpenID Connect (OIDC) is a modern JSON-based identity layer built on OAuth 2.0, suited for mobile apps and consumer portals such as "Login with Google." Both protocols verify identity and establish a valid Salesforce session. 📌 Illustrative Dual-SSO Architecture: Picture a company running a single Salesforce org for both staff and customers. Internal employees authenticate through corporate Microsoft Entra ID using SAML 2.0 SSO on the org's My Domain login page—one employee credential covers their daily tools. Meanwhile, external users on the Experience Cloud customer portal sign in via "Login with Google," powered by an Op...

In plain words: PingID (Ping Identity) is an enterprise identity and multi-factor authentication (MFA) provider. Integrating Ping Identity with Salesforce allows users to authenticate into custom applications or verify their credentials securely using modern protocols like OpenID Connect (OIDC) and OAuth 2.0. In Salesforce, this can be done natively via Auth. Providers (Single Sign-On) or programmatically using Apex REST controllers . Enterprise identity management requires unified authentication across cloud platforms, mobile applications, and internal tools. Rather than managing separate sets of credentials inside Salesforce, organizations use central Identity Providers (IdPs) like Ping Identity (PingFederate / PingOne / PingID). This guide explains how OAuth 2.0 authorization code flows work between Ping Identity and Salesforce, complete with step-by-step Apex and UI implementations.