Skip to content
Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
AdministrationBeginner

Delegated Authentication

Delegated Authentication is a Salesforce single sign-on option that hands password checking to a web service you host, instead of validating it against the Salesforce user record.

§ 01

Definition

Delegated Authentication is a Salesforce single sign-on option that hands password checking to a web service you host, instead of validating it against the Salesforce user record. Salesforce keeps the username and issues the session; your service owns the verdict.

When a user with the Is Single Sign-On Enabled permission submits the login form, Salesforce posts a SOAP request to the Delegated Gateway URL set on Single Sign-On Settings. It carries the username, the password as typed, and the source IP. Your service checks that against LDAP or Active Directory and answers true or false.

Salesforce also supports SAML and authentication providers built on OpenID Connect. Delegated Authentication is the only one of those routes where a live outbound callout stands between your users and a session.

§ 02

In plain English

Instead of checking your password itself, Salesforce asks a computer at your own company whether the password you typed is correct. That computer answers yes or no, and Salesforce takes the answer at face value. If that computer is down, nobody gets in.

§ 03

Worked example

scenario · real-world use

A 900-seat insurance carrier keeps every staff credential in on-premises Active Directory. Their admin points Delegated Gateway URL at https://sso.carrier.example.com/services/AuthService and grants Is Single Sign-On Enabled to the Claims Adjuster profile. An adjuster types their directory password into the Salesforce login page. Salesforce posts the callout to that endpoint, the service finds a match in Active Directory, and the session opens. When the DMZ certificate expires, every adjuster sees a generic login failure and the reason sits in Delegated Authentication Error History.

§ 04

What happens between the login form and your endpoint

Build the endpoint from the WSDL

Generate your server stub from the Delegated Authentication WSDL rather than hand-writing the XML. The documentation is blunt about this: element names, namespaces, and capitalization have to match exactly, and a generated stub gets that right for free. What comes back is one boolean, with no room for a reason code. A wrong password and a crashed service look identical. Contrast that with SAML, where the browser carries a signed assertion and Salesforce makes no outbound call of its own. Delegated Authentication inverts that. Salesforce places the call and trusts one bit of the answer.

Three switches, and the two people mix up

The gateway URL sits on one page, but the feature is gated per user. Fill in Delegated Gateway URL on Single Sign-On Settings, then grant Is Single Sign-On Enabled on a profile or permission set. Anyone without that permission keeps using a Salesforce password as though nothing changed, which is how you pilot this safely. The third switch, Disable login with Salesforce credentials, takes the Salesforce password away from the people who do hold it. Select it last, once the endpoint has earned it.

Your endpoint becomes a login dependency

The service must be reachable from Salesforce servers, so it needs a host in your DMZ published under an external DNS name, with TLS and a certificate from a trusted provider. The one nobody writes down is availability, because a delegated login is a synchronous call with no cached fallback. Salesforce gives your service 10 seconds to answer. Past that the attempt fails and the user is told the corporate authentication service is down. A directory that is merely slow reads exactly like a dead one. A dead endpoint locks out everyone holding the permission at once, including whoever would fix it. The SOAP API Developer Guide says it plainly: do not enable single sign-on for your system administrator account.

Password management leaves Salesforce

Once a user is delegated, Salesforce stops managing their password, so self-service reset is switched off and anyone who tries is pointed at their admin. Expiry, complexity, lockout thresholds, and reuse history become properties of your directory rather than Salesforce Password Policies. That is usually the point, since one policy is easier to defend in an audit than two that drift apart. The trap is delegating a department and forgetting that the Salesforce rules now govern nobody in it.

Debugging a login you cannot see

Failures split across separate logs, which is what makes this tedious. Login History records the attempt and its outcome from the Salesforce side. Delegated Authentication Error History records the callout errors, where timeouts, TLS failures, and malformed responses surface. It holds only the 21 most recent, so during an outage it rolls over while you read it. Your own service log holds the reason a false was returned, and Salesforce cannot see it. Correlate all three before blaming any one of them. The usual culprits are dull: an expired certificate, a firewall change, or a directory answering slowly under load.

Where it stands in 2026

Delegated Authentication is still published in current Salesforce Help, and it does not appear on the Active Product and Feature Retirements article. Nothing has been renamed and no end date announced, so an org running it today is not on a clock. That is a different statement from recommending it. SAML and authentication providers reach the same outcome, an external system deciding who gets in, without a callout on the critical path and without a password reaching Salesforce. If you inherited this setup, run SAML alongside it and pull the permission wave by wave.

§ 05

Set up Delegated Authentication

Two pieces have to exist: the web service, and Setup pointing at it. Build the service first, then wire it to one pilot user.

  1. Download the WSDL

    From Setup, enter API in the Quick Find box, select API, then download the Delegated Authentication WSDL. It sits beside the Enterprise and Partner WSDLs.

  2. Prove Salesforce can reach it

    Call the endpoint from outside your own network before you touch Setup. An internal hostname resolves from your desk and fails from Salesforce, which is the usual first-attempt failure.

  3. Point Salesforce at the endpoint

    From Setup, open Single Sign-On Settings, click Edit, and paste the HTTPS address into Delegated Gateway URL. Saving it routes nobody yet.

  4. Enable one pilot user, not a profile

    Assign Is Single Sign-On Enabled through a permission set held by one test account nobody depends on. Log in as that user and watch the request land in your service log.

  5. Break it on purpose before you go wide

    Stop the service, retry the pilot login, then open Delegated Authentication Error History from the Quick Find box. It needs Modify All Data, which is a bad thing to discover at 9am on a Monday.

Delegated Gateway URLremember

One field for the whole org. There is no per-profile override, so a phased migration moves people off the permission instead.

Is Single Sign-On Enabledremember

Grantable on a profile or a permission set. Use a permission set, so you can pull it from one person without editing a profile everyone shares.

Disable login with Salesforce credentialsremember

Applies only to users who hold the permission. Everyone else keeps a Salesforce password whatever this box says.

Gotchas
  • A sandbox refresh copies the gateway URL, but sandbox usernames carry the sandbox suffix, so your service will not find them.
  • Delegated users cannot reset their own password, so your help desk absorbs every reset request.
  • An expired certificate on the DMZ host reads as a total outage, because there is no degraded mode.

Prefer this walkthrough as its own page? How to Delegated Authentication in Salesforce, step by step

§ 06

How organizations use Delegated Authentication

Contractors reach Salesforce only while an assignment is active. The endpoint checks the roster alongside the password and returns false the day a contract ends.

Authenticates against a system that predates SAML and cannot be fronted by a modern identity provider, so delegated authentication bridges the gap.

Has head office on SAML while plant-floor profiles stay delegated, pulling the permission department by department until the old endpoint can be switched off.

Was this entry helpful?
Help us write better definitions. Quick reactions or detailed edit suggestions.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He writes and edits salesforcedictionary.com, published by KineticBit Inc., to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.

§

Test your knowledge

+5 pts / day

Q1. A user with the Is Single Sign-On Enabled permission submits the Salesforce login form. What does Salesforce send to the delegated gateway?

Q2. Your delegated authentication endpoint goes offline at 8am on a weekday. What happens to logins?

Q3. Which change makes the external service the only way a delegated user can log in?

§

Discussion

Loading…

Loading discussion…