All articles

💬 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: Think of OAuth 2.0 as a hotel key card system for Salesforce APIs. An authorization code is the one-time reservation voucher you hand to the front desk. An access token is the short-lived plastic key card that opens specific doors. A refresh token is the long-lived master voucher that lets you print a new key card at the kiosk whenever your current one expires. Scopes define which rooms that card can unlock, and grant types are the different check-in procedures used to get the card. 📌 Worked example: Your middleware integration logs show three distinct steps during setup: first, a user signs in and Salesforce returns an authorization code (a short-lived voucher). Second, the middleware exchanges that code at the token endpoint for an access token and a refresh token. Two hours later, the access token expires—but no user is prompted to log in again because the middleware quietly sends the refresh token to mint a fresh access token in the ...

💬 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: A Connected App is the security contract between your Salesforce org and an external application. It defines which OAuth 2.0 flows the integration may use, which scopes (token permissions) it can request, which users are allowed to authenticate, and what session or IP policies apply. As Salesforce transitions toward External Client Apps (ECAs) —which separate developer configuration from administrator policies and are closed by default—understanding how both models govern API access is essential for every architect and developer. 📌 Illustrative Integration Scenario: Imagine a partner integration request lands on your desk in 2026. Instead of creating a classic Connected App (where creation may be restricted by default in newer org configurations to encourage modern standards), you provision an External Client App , configure it for the OAuth 2.0 JWT Bearer or Client Credentials flow, and grant access strictly through an assigned Permission S...

💬 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...

⚡ 1-Minute Summary The Golden Question: One simple question picks your OAuth 2.0 flow: Is a human sitting in front of a screen, or is a machine talking to a machine? Identity Resilience: Always enforce Multi-Factor Authentication (MFA) at your Single Sign-On (SSO) Identity Provider, and keep one dedicated "break-glass" System Administrator account outside of SSO in case your IdP goes down. How Token Power Works: An access token's effective permission is the intersection of the OAuth Scope AND the User's Salesforce Profile/Permission Sets —never one by itself. 💬 In plain words: OAuth 2.0 is how external applications connect to Salesforce without ever seeing or storing your password . Instead of handing over a password, Salesforce gives the external app a temporary digital hotel key card called an Access Token . Different scenarios require different ways of getting that key card: Web Server Flow with PKCE is f...

💬 In plain words: A Salesforce sandbox without realistic data is like a theater stage without props. Sandbox seeding is the practice of loading a realistic, anonymized (masked) slice of production-shaped data—with all parent-child relationships intact—into your lower sandboxes so testing actually proves your code works. Because Full Copy sandboxes are expensive and can only be refreshed once every 29 days, a regularly refreshed Partial Copy or Developer sandbox populated with an automated seeding script beats waiting a month for a Full refresh. 📌 Example: Imagine your UAT sandbox only has six Account records named "Test test" with zero child Contacts or Opportunities . It is no surprise when bugs slip straight into Production! Instead, seed your sandbox with a masked, referentially intact 5% slice of production data—Accounts linked to their real-world shape of Contacts, Cases, and custom CPQ/Billing records—refreshed before every sprint. Testing a...