Explore technology. Understand yourself.

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