Delegated Authentication
Delegated Authentication in Salesforce is the legacy single sign-on mechanism that lets the org outsource login verification to an external authentication service through a SOAP web service callout.
Definition
Delegated Authentication in Salesforce is the legacy single sign-on mechanism that lets the org outsource login verification to an external authentication service through a SOAP web service callout. When a user logs in, Salesforce sends their credentials to the configured external endpoint; the endpoint validates against the customer's identity store (LDAP, on-prem AD, custom directory) and returns a true/false response. The pattern predates SAML and OpenID Connect; modern orgs almost universally use SAML SSO, Auth Providers, or Identity Connect rather than Delegated Authentication.
Delegated Authentication exists for backward compatibility with very early Salesforce SSO deployments. The mechanism is functional but has significant downsides: it requires an internet-reachable SOAP endpoint, the password traverses the network on every login, the external service must be highly available (downtime equals login failure), and the audit trail is split between Salesforce and the external service. Modern SSO patterns (SAML, OAuth/OIDC) eliminate most of these issues. New SSO deployments should default to SAML or Auth Providers; orgs still on Delegated Authentication should plan migration.
Why Delegated Authentication is the legacy SSO pattern modern orgs should migrate off
Where Delegated Authentication lives in setup
Setup, Security, Single Sign-On Settings includes the Delegated Authentication configuration. The page captures the endpoint URL the org sends authentication callouts to, certificate validation settings, and login behavior on callout failure. The configuration is enabled per profile (Profile, Delegated Authentication checkbox); users in profiles with the checkbox enabled go through the callout, others use standard Salesforce password verification.
The SOAP callout and what gets sent
On login, Salesforce constructs a SOAP request containing the username, password, source IP, and User Agent, and sends it to the configured endpoint. The endpoint validates against the customer's authentication source and responds with true (allow login) or false (deny). The SOAP envelope is the pattern; the customer-side implementation is whatever the customer's authentication service exposes. The endpoint must accept HTTPS, present a valid certificate, and respond within a timeout (typically 10 seconds).
Endpoint requirements and the operational burden
The Delegated Authentication endpoint must be internet-reachable from Salesforce, highly available (any downtime blocks every user's login), TLS-protected with a certificate Salesforce trusts, and capable of validating credentials against the org's actual identity store. Most customer implementations sit on top of LDAP or Active Directory through a custom web service. The operational burden is real: the endpoint needs monitoring, redundancy, and certificate management. Modern SSO patterns externalize the same authentication without these per-callout operational requirements.
Failure modes and the login-blocking risk
Endpoint downtime blocks every Delegated Authentication user from logging in. Slow endpoint responses (over the timeout) produce login failures even when the endpoint would eventually validate correctly. Certificate expiration on the endpoint blocks authentication. Network issues between Salesforce and the endpoint produce intermittent failures. Each failure mode is a production incident; the operational discipline to prevent them is significant. Most orgs that experience repeated Delegated Authentication outages migrate to SAML, where the IdP handles availability and Salesforce never depends on a per-login callout.
Audit, logging, and the split trail
Delegated Authentication logs to two places: the Salesforce login history (the request initiation) and the customer endpoint's own log (the validation result). Reconstructing what happened during a login requires correlating both. Modern SSO logs are usually unified at the IdP, simpler to audit. The split trail is one of the smaller-but-real reasons regulated orgs prefer modern SSO; compliance reviewers prefer one log to read.
Migration path to SAML or OAuth
Migrating from Delegated Authentication to SAML SSO is straightforward but operationally heavy. The pattern: configure SAML SSO alongside the existing Delegated Authentication, test with a pilot user population on the new path, switch users from Delegated Authentication to SAML by removing the Delegated Authentication checkbox on their profile, retire the Delegated Authentication endpoint after the last user migrates. Most migrations take 1 to 3 months depending on the size of the user population and the complexity of the customer-side IdP setup.
When Delegated Authentication is the right choice today
Almost never for new deployments. SAML, Auth Providers (OAuth/OIDC), or Identity Connect serve every Delegated Authentication use case with less operational risk. The exception: integration with a very old internal authentication service that does not support SAML or OAuth, and the customer cannot front it with a SAML adapter. In that case, Delegated Authentication is the bridge until the internal service is modernized; the migration to SAML usually follows within a year.
How to manage Delegated Authentication or plan migration off it
For orgs on Delegated Authentication today, the pattern is: monitor the endpoint health, plan migration to SAML or Auth Providers, execute the migration over months. For new deployments, do not use Delegated Authentication; pick SAML or OAuth instead.
- Assess whether Delegated Authentication is the right tool
New deployments should default to SAML SSO or Auth Providers. Delegated Authentication is for legacy continuity, not new design.
- For existing Delegated Authentication, monitor endpoint health
Uptime monitoring, certificate expiration alerts, response-time tracking. The endpoint is a single point of failure for user login.
- Plan migration to SAML SSO or Auth Providers
Configure the new SSO path alongside Delegated Authentication. Pilot with a small user group on the new path; validate functionality.
- Migrate users from Delegated Authentication to the new SSO
Remove the Delegated Authentication checkbox on profiles as users migrate. Users keep their existing user records and identity; only the login mechanism changes.
- Verify SAML or Auth Provider login works for migrated users
Each migration wave needs verification. Failed migrations leave users unable to log in; rollback to Delegated Authentication is fast (re-enable the checkbox) but disruptive.
- Retire the Delegated Authentication endpoint after last user migrates
Once no profile has the checkbox enabled, the endpoint is unused. Decommission per the customer's infrastructure retirement process.
- Document the migration in the change log and audit trail
The migration is a security-relevant change; document the timeline, the validation steps, the rollback plan.
The customer's HTTPS SOAP endpoint that validates credentials.
Whether Salesforce validates the endpoint's TLS certificate. Always enable for production.
The Delegated Authentication checkbox on each profile. Users in profiles with the checkbox go through the callout.
Whether Salesforce blocks login on callout failure (the secure default) or falls back to local password.
SAML SSO or Auth Providers (OAuth/OIDC) for modern replacement.
- Endpoint downtime blocks every user's login. The endpoint is a single point of failure that needs high-availability operational practice.
- Certificate expiration on the endpoint blocks authentication. Add to the cert-rotation monitoring inventory.
- The password traverses the network on every login (TLS-protected but still server-visible). Modern SSO patterns avoid this entirely.
- Audit trail is split between Salesforce and the customer endpoint. Reconstructing login events requires correlating both.
- New SSO deployments should default to SAML or OAuth. Delegated Authentication is for legacy continuity, not new design.
Trust & references
Cross-checked against the following references.
- Delegated Authentication referenceSalesforce
- SSO overviewSalesforce
Straight from the source - Salesforce's reference material on Delegated Authentication.
- Delegated AuthenticationSalesforce Help
- Single Sign-On OverviewSalesforce Help
- Auth ProvidersSalesforce Help
Hands-on resources to go deeper on Delegated Authentication.
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. What is Delegated Authentication?
Q2. What's the modern alternative to Delegated Authentication?
Q3. When is Delegated Authentication still appropriate?
Discussion
Loading discussion…