Salesforce My Domain, MFA and Delegated Authentication

💬 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 IdP outage cannot lock admins out of Salesforce; those accounts enforce native Salesforce MFA, strict IP ranges, and automated login alerts.

🔑 Key Points

• My Domain Is the Foundation: Every Salesforce org uses a My Domain subdomain (such as https://yourcompany.my.salesforce.com) to isolate cookies across orgs, render Lightning Web Components, customize login branding, and route users to specific Identity Providers.
• Preventing Login Bypass: Enabling Prevent login from https://login.salesforce.com in My Domain settings stops users from bypassing your custom login page policies and attempting direct credentials against generic Salesforce endpoints.
• MFA Enforcement Paths: Salesforce contractually and technically requires MFA for all interactive human logins. You can satisfy this either through native Salesforce MFA (Salesforce Authenticator, TOTP apps, WebAuthn/FIDO2 security keys, or built-in authenticators) or by enforcing MFA upstream at your SSO Identity Provider.
• Break-Glass Admin Resilience: Enforcing SSO on every single user profile turns an external IdP outage into a total administrative lockout. Always keep at least two dedicated administrator accounts on a profile that permits direct login with native Salesforce MFA.
• Delegated Authentication Tradeoffs: Unlike federated SSO (where passwords never reach Salesforce), Delegated Authentication captures the username and password in Salesforce and sends them over TLS via a SOAP callout to an endpoint you host and secure.

🧠 Core Rule: Use My Domain to control your org's front door, enforce MFA at the Identity Provider for SSO users (while keeping native-MFA break-glass admins outside SSO), and prefer SAML or OpenID Connect over Delegated Authentication whenever possible.

🔍 Concept: How My Domain, MFA, and Delegated Authentication Fit Together

Securing access to a Salesforce org requires answering three separate architectural questions: Where do users arrive to log in? How strongly must they prove their identity? And which system verifies their credentials? Let's walk through how Salesforce splits these responsibilities across My Domain, Multi-Factor Authentication, and Delegated Authentication.

1. My Domain: Your Org's Dedicated Front Door

Historically, users logged in through https://login.salesforce.com (or https://test.salesforce.com for sandboxes) before being redirected to a shared instance URL like na139.salesforce.com. Today, My Domain is required and enabled by default in all Salesforce orgs. It assigns your org a permanent, instance-independent subdomain (yourcompany.my.salesforce.com) and provides critical security controls under Setup → Identity → My Domain:

• Authentication Configuration: You choose which authentication services appear on your login screen—whether that is the standard username/password form, one or more SAML 2.0 Identity Providers, or OpenID Connect Auth. Providers.
• Login Policy Enforcement: Checking Prevent login from https://login.salesforce.com ensures that users cannot sidestep your My Domain login screen. You can also check Prevent SOAP API login from https://login.salesforce.com to require API integrations to use your My Domain endpoint.
• Redirection Behavior: You control how legacy instanced URLs redirect to your current My Domain name, preventing broken bookmarks during org migrations or Hyperforce instance moves.

2. Multi-Factor Authentication (MFA) and Session Assurance Levels

Under the Salesforce Multi-Factor Authentication requirement, all internal users who log in to the user interface must use MFA. Internally, Salesforce tracks authentication strength using Session Security Levels:

• Standard Assurance: Assigned when a user logs in with only a single factor (such as username and password, or a SAML assertion that does not declare high-assurance authentication).
• High Assurance: Assigned when a user completes native Salesforce MFA (via Salesforce Authenticator, a Time-based One-Time Password [TOTP] generator app, or a FIDO2/WebAuthn hardware security key) or when a SAML assertion maps to High Assurance in Session Settings.

Architects can require a High Assurance session level before a user is allowed to perform sensitive operations—such as exporting or printing reports, viewing dashboards, accessing Connected Apps, or opening critical Setup pages. If a user holds only a Standard session when they click an restricted report export button, Salesforce prompts them for step-up authentication on the spot.

3. Delegated Authentication: How It Differs from Federated SSO

It is easy to confuse Federated Authentication (SAML 2.0 and OpenID Connect) with Delegated Authentication, because both let users log in with their corporate credentials. However, the network mechanics and security risks are completely different:

• In Federated SSO (SAML / OIDC): The user types their password directly into the Identity Provider's browser screen. Salesforce never sees, touches, or transmits the user's password. It only receives a digitally signed XML assertion or JSON token.
• In Delegated Authentication: The user types their username and password directly into the Salesforce login screen (or passes them in a SOAP/REST login call). When Salesforce sees that the user's Profile or Permission Set has the Is Single Sign-On Enabled permission active—and Delegated Authentication is configured in Single Sign-On Settings—Salesforce does not check its own password database. Instead, Salesforce wraps the username, plain-text password, and client source IP into a SOAP 1.1 XML message and sends an outbound HTTPS POST request to a web service URL that your company hosts. Your web service checks your internal directory (such as a legacy LDAP or custom database) and returns <Authenticated>true</Authenticated> or <Authenticated>false</Authenticated>.

Because raw passwords flow through Salesforce to your custom web service on every login, your team assumes full responsibility for securing that endpoint, maintaining mutual TLS (mTLS) certificates, preventing credential logging, and guaranteeing 24/7 uptime. For new implementations, always place a modern SAML or OIDC Identity Provider in front of legacy directories instead of building a Delegated Authentication web service.

🎬 Scenario Walkthrough: When the Corporate IdP Goes Down and Nobody Can Get In

Picture a Monday morning at 9:00 AM: an organization's corporate Identity Provider suffers a regional outage, or its SAML signing certificate expires over the weekend. All 2,000 sales and service employees are locked out of Salesforce. Worse yet, when the lead Salesforce Administrator tries to log in to upload the new certificate or temporarily re-enable password logins, they are locked out too.

The Flawed Approach: During the security hardening project, the team enabled the Is Single Sign-On Enabled user permission on every profile—including the standard System Administrator profile—and unchecked the native Login Form on the My Domain Authentication Configuration page because leaving any password login active "felt like a security loophole."

Why This Breaks: A direct login path is only a loophole if you leave it unguarded. When you force 100% of administrator accounts through an external IdP, that external system becomes a single point of failure for your ability to administer and recover your own Salesforce org. You cannot even log into Setup to disable SSO or swap an expired certificate without opening a high-severity support case with Salesforce and undergoing manual identity verification.

The Resilient Approach: Clone the System Administrator profile into an SSO System Administrator profile for daily admin work, and reserve a dedicated Break-Glass Administrator profile (with Is Single Sign-On Enabled unchecked) for two emergency accounts. Protect those two accounts with native Salesforce MFA (such as hardware FIDO2 security keys), strict Profile Login IP Ranges tied to your corporate VPN, and a Real-Time Event Monitoring alert whenever they authenticate. Even if the standard login form is hidden on the My Domain page, break-glass admins can append ?login to the My Domain URL (for example, https://yourcompany.my.salesforce.com/?login) as long as the Login Form service is not completely disabled in Authentication Configuration—or better yet, keep the Login Form enabled for emergency use while enforcing Is Single Sign-On Enabled on all workforce profiles so regular users still cannot use passwords.

The Payoff: During the next IdP disruption, administrators log in immediately via the break-glass account, diagnose the SAML failure in seconds, and either upload the replacement certificate or manage recovery without waiting hours for external escalation.

🛠️ Worked Example: Understanding the Delegated Authentication SOAP Contract

Even though you should avoid Delegated Authentication in new designs, architects frequently inherit legacy orgs that still use it or need to troubleshoot why a legacy login endpoint is rejecting users. Let's inspect the exact XML contract that Salesforce sends and expects back.

Prerequisites and Security Context

• Where it is configured: Under Setup → Identity → Single Sign-On Settings, in the Delegated Authentication section via the Delegated Gateway URL field.
• Network & Certificate Requirements: The endpoint must use HTTPS (port 443) with a certificate signed by a trusted Certificate Authority included in Salesforce's list of outbound root CAs. For production security, check Force Delegated Authentication Callout to Use Mutual SSL and upload a mutual authentication certificate so your endpoint can verify the request genuinely came from Salesforce.
• User Activation: Only users with the Is Single Sign-On Enabled permission (on their Profile or a Permission Set) trigger this callout. System Administrators should remain exempt so a broken web service does not lock admins out.

1. Outbound SOAP Request Sent by Salesforce

When an SSO-enabled user attempts to log in, Salesforce sends an HTTP POST containing the following SOAP 1.1 envelope (note that this is an illustrative protocol payload based on the official Salesforce WSDL; escape all XML characters if testing with mock tools):

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <Authenticate xmlns="urn:authentication.soap.sforce.com">
      <username>Alex.Rivera@company.com</username>
      <password>MyPlainTextSubmittedPassword!</password>
      <sourceIp>203.0.113.42</sourceIp>
    </Authenticate>
  </soapenv:Body>
</soapenv:Envelope>

2. Expected SOAP Response Returned by Your Endpoint

Your endpoint must validate those credentials against your backing store and respond within Salesforce's callout timeout window with a rigid boolean <Authenticated> element:

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Body>
    <AuthenticateResult xmlns="urn:authentication.soap.sforce.com">
      <Authenticated>true</Authenticated>
    </AuthenticateResult>
  </soapenv:Body>
</soapenv:Envelope>

How to Verify and Troubleshoot Failures

1. Check Delegated Authentication Error History: In Setup, navigate to Identity → Delegated Authentication Error History. Salesforce records the last 20 login errors for your org, showing the timestamp, username, and exact HTTP/SOAP failure reason (such as a 500 Internal Server Error, SSL handshake failure, or invalid XML namespace).
2. Inspect Login History: Open Setup → Identity → Login History. Look at the Login Type and Status columns to confirm whether Salesforce attempted a Delegated Authentication callout or rejected the user earlier due to Profile IP range restrictions or a locked account.

🧭 360 Card — My Domain, MFA & Delegated Authentication

Rule: Enforce MFA at your Identity Provider (the corporate front door) for all SSO users, and always maintain dedicated break-glass administrator accounts outside SSO protected by native Salesforce MFA.

Benefit: Centralizing MFA at the IdP gives employees a single authentication prompt across all enterprise apps while keeping device posture, location rules, and conditional access in one place.

Tradeoff: If SSO is the only enabled login path for every profile and your IdP goes offline, nobody—including your own administrators—can enter Salesforce to fix it.

Boundaries & Limits: My Domain is mandatory for SSO and Lightning components. Non-interactive machine-to-machine OAuth flows (such as JWT Bearer and Client Credentials) are exempt from human MFA prompts, whereas High Assurance session levels can be required inside Salesforce for sensitive actions like report exports.

Anti-Pattern — Delegated Authentication for New Builds: While Delegated Authentication connects legacy credential stores that lack SAML/OIDC support, it transmits plain-text passwords over the wire to your custom endpoint on every login, transferring uptime and credential-handling risk directly onto your team.

Post-Login Controls: Login authentication is only half the boundary. Pair it with risk-based Session Timeouts, strict Login IP Ranges on integration profiles, and Real-Time Event Monitoring Transaction Security Policies for step-up verification.

Scaling for M&A: During an acquisition, you can configure the acquired company's IdP as a second SAML configuration on your My Domain page, boarding new users quickly without rushing an underlying directory merge.

⚠ ARCHITECT & INTERVIEW TRAP: Headless machine-to-machine OAuth flows (such as the OAuth 2.0 JWT Bearer flow and Client Credentials flow) are exempt from interactive human MFA requirements—but exempt from human MFA does not mean exempt from security controls! When an interviewer asks how you secure integration users without MFA, explain that security shifts to the application layer: X.509 digital certificates, strict Profile Login IP Ranges, short-lived access tokens, the Api Only user permission (or Salesforce Integration license), and least-privilege Permission Sets.

❓ Core Q&A and Architecture Scenarios

Q: Where should MFA be enforced in an SSO-enabled Salesforce org, and which user populations require special handling?

🎯 Say this first: Enforce MFA upstream at the corporate Identity Provider for workforce SSO users, and carve out explicit handling for three special populations: break-glass administrators (direct login with native Salesforce MFA), headless integration accounts (certificate/secret flows with IP restrictions), and any transitional password-login users (native Salesforce MFA).

A: A complete enterprise MFA strategy addresses four distinct groups in your org:

• 1. Workforce SSO Users: Enforce MFA at the corporate IdP (such as Okta or Microsoft Entra ID). When the IdP authenticates the user with MFA before issuing the SAML assertion or OIDC token, it satisfies Salesforce's contractual MFA requirement and keeps conditional access rules (device trust, geolocation, risk scoring) centralized. To ensure Salesforce recognizes that the IdP session completed MFA, map your SAML Identity Provider to High Assurance under Setup → Session Settings → Session Security Levels.
• 2. Break-Glass System Administrators: Never put 100% of your System Administrators on SSO. Keep at least two emergency admin accounts on a dedicated Profile where Is Single Sign-On Enabled is unchecked. Protect them with native Salesforce MFA, corporate VPN IP ranges, and quarterly login drills so you know the password and MFA hardware key still work.
• 3. Headless Integration / Machine Users: API integration accounts never sit at a browser to tap a push notification. Configure them on the Salesforce Integration license (or with the Api Only permission), authenticate via OAuth 2.0 JWT Bearer or Client Credentials flows, and lock down their Profile Login IP Ranges to the middleware's static outbound IPs.
• 4. Transitional or Contractor Direct-Login Users: Any human users who have not yet migrated to the corporate IdP must have native Salesforce MFA enforced directly in Salesforce until their accounts are federated.

Q1: Why is Delegated Authentication considered an architectural liability compared to SAML 2.0 or OpenID Connect?

A1: Delegated Authentication introduces four significant operational and security burdens that federated protocols avoid:

• Plain-Text Password Transit: Every time a user logs in through the UI or passes a password to the API, Salesforce sends the user's raw password inside a SOAP XML payload to your custom web service. Even over HTTPS with mutual TLS, a misconfigured proxy, APM tracing tool, or debug log in your middleware can accidentally write employee passwords to disk in plain text.
• Custom Infrastructure Ownership: Instead of relying on battle-tested SAML/OIDC endpoints managed by an enterprise IdP vendor, your internal team must code, patch, load-balance, and monitor a high-availability SOAP endpoint. If your web service slows down or crashes, Salesforce logins fail across the board.
• No Cryptographic Assertions or Context: Delegated Authentication only returns a boolean true or false. Unlike SAML 2.0 or OpenID Connect, it cannot pass user attributes for Just-In-Time (JIT) provisioning, cannot convey whether MFA was performed, and cannot prompt the user with an interactive MFA challenge screen during the web service callout.
• Practical Migration Path: Because Delegated Authentication is triggered per Profile or Permission Set via the Is Single Sign-On Enabled permission—or can be scoped as you transition profiles to SAML—you can migrate off Delegated Authentication incrementally, moving one user profile at a time to SAML 2.0 or OIDC without an all-at-once cutover.

Q2: During an M&A acquisition, 400 users from an acquired company need access to your Salesforce org within 60 days while staying on their existing IdP. What are your options and tradeoffs?

A2: You do not need to wait for IT to merge the two companies' Active Directory forests before onboarding those 400 users into Salesforce:

• The 60-Day Tactical Architecture (Multi-IdP SSO): Salesforce supports configuring multiple SAML 2.0 Single Sign-On configurations and multiple OpenID Connect Auth. Providers simultaneously in the same org. You add the acquired company's IdP as a second SAML configuration in Single Sign-On Settings and enable it alongside your primary IdP in My Domain → Authentication Configuration.
• Routing and Provisioning: Users can either click their respective company's IdP button on the My Domain login screen, or use SP-initiated / IdP-initiated deep links specific to their directory. Use Just-In-Time (JIT) provisioning or a scoped data load to assign the acquired users to least-privilege Profiles and Permission Sets, and populate a distinct FederationIdentifier prefix so employee numbers from the two companies never collide.
• The Strategic Tradeoff: Running two IdPs side-by-side solves the 60-day business deadline cleanly, but if left indefinitely, it doubles certificate rotation tracking, complicates user deprovisioning, and splits audit logs. Always pair the 60-day multi-IdP rollout with a 6-to-12-month milestone to retire the secondary SAML setting once corporate identity directories are consolidated.

Q3 (Comparison): If our org already uses Single Sign-On (SSO), do we still need Multi-Factor Authentication (MFA)?

A3: Yes—because SSO and MFA solve two completely different problems:

• SSO decides where you authenticate: It centralizes login at your Identity Provider so users do not juggle separate passwords for every cloud app.
• MFA decides how strongly you authenticate: It requires two independent proofs of identity (something you know, like a password, plus something you have, like a hardware key or authenticator app) so a phished password alone cannot compromise the account.
• How They Work Together: Combining SSO with single-factor password login only means an attacker who steals one password gets into every corporate app at once. The correct pattern is to enforce MFA at the IdP during the SSO login, satisfying Salesforce's MFA requirement while protecting your entire application portfolio.

Q4: Beyond the initial login screen, what other session and network controls should you lock down in Salesforce?

🎯 Say this first: Lock down four post-login layers: set Session Timeouts by user risk profile, require High Assurance sessions for sensitive operations, enforce strict Login IP Ranges on machine integration profiles, and deploy Real-Time Event Monitoring Transaction Security Policies for anomalous behavior.

A4: Once a session is established, protect it using four defence-in-depth settings:

• 1. Profile-Level Session Timeouts: Rather than relying on a single org-wide timeout, configure shorter inactivity timeouts (such as 15 or 30 minutes) on administrative and high-privilege profiles, and enable Force logout on session timeout so expired browser tabs immediately terminate the session.
• 2. High Assurance Session Requirements: Under Session Settings → Session Security Levels, require a High Assurance session for sensitive actions like Export Reports. Even if an attacker hijacks a standard-assurance session, they are blocked or forced through step-up verification before exfiltrating bulk data.
• 3. Login IP Ranges on Integration Profiles: A backend integration running on AWS, Azure, or MuleSoft only ever calls Salesforce from known static IP addresses or NAT gateways. Set strict Login IP Ranges on the integration user's Profile so a leaked token or certificate cannot be used from an attacker's workstation.
• 4. Transaction Security Policies (Shield / Real-Time Event Monitoring): Where licensed, configure Real-Time Event Monitoring policies on ReportEvent, ApiEvent, or LoginEvent to automatically block or require MFA step-up when a user queries an unusually large number of rows or logs in from an unfamiliar country.

Q5: Does the Salesforce MFA requirement apply to headless API integration users?

A5: No. Automated machine-to-machine logins—specifically those using the OAuth 2.0 JWT Bearer flow, OAuth 2.0 Client Credentials flow, or certificates—are excluded from the interactive human MFA requirement because no human is present to approve an authenticator prompt. However, to qualify cleanly and remain secure, those accounts should never be used for shared human UI logins. Restrict them with the Salesforce Integration user license (or the Api Only permission), authenticate via short-lived OAuth tokens backed by certificates or rotated secrets, restrict their Profile Login IP Ranges, and grant data access strictly through least-privilege Permission Sets.

📝 2-Minute Self-Check

Q1: A CI/CD pipeline job needs to deploy metadata to a Salesforce org overnight with no human present. Which OAuth flow should it use, and how does MFA apply?

Answer & Explanation: Use the OAuth 2.0 JWT Bearer flow (or the OAuth 2.0 Client Credentials flow), authenticating a pre-authorized integration user via an X.509 digital certificate uploaded to an External Client App or Connected App. Because this is a non-interactive machine-to-machine authentication flow, human MFA prompts do not apply; instead, the private signing key and Profile IP restrictions protect the account.

Q2: Your corporate Identity Provider suffers an outage and nobody—including your System Administrators—can log into Salesforce to update the SSO settings. Which two configuration choices caused this total lockout?

Answer & Explanation: First, the team enabled the Is Single Sign-On Enabled permission on all administrator profiles instead of keeping a dedicated break-glass admin profile exempt from SSO. Second, they either failed to maintain direct login capability (with native Salesforce MFA) on the My Domain authentication service or lost track of the break-glass account credentials.

🔗 Next Concept Follow-Up: Enforcing Step-Up Security Inside an Active Session

Follow-Up Q: Suppose a user logs in via corporate SAML SSO, and you want them to be able to view Accounts normally, but require them to complete a fresh MFA challenge before exporting any Salesforce report. How does Salesforce know whether the incoming SAML assertion already included MFA?

A: By default, Salesforce assigns a Standard session security level to SAML SSO logins unless you configure Session Security Levels in Setup. Under Setup → Identity → Session Settings, you can decide whether a specific SAML Identity Provider is mapped to Standard or High Assurance.

If you leave the SAML IdP mapped to Standard, and you check Raise session to high assurance level when exporting or printing reports in Session Settings, any SSO user who clicks Export on a report will immediately be prompted by Salesforce to complete a native High Assurance challenge before the file downloads. Alternatively, if your corporate IdP already enforces strict MFA for every login and you want to avoid double-prompting users inside Salesforce, you map that SAML setting directly to High Assurance in Session Settings so the SSO session satisfies high-assurance checks from the moment the user lands in the org.

📚 Official Salesforce Documentation

To verify current release details, certificate authorities, and setup steps, consult these primary Salesforce resources:

• Review My Domain in Salesforce Help for subdomain login policies, redirection rules, and Authentication Configuration settings.
• Consult Multi-Factor Authentication (MFA) in Salesforce Help for supported verification methods, SSO IdP rules, and API integration user exemptions.
• Refer to Configure Org for Delegated Authentication Single Sign-On for the SOAP WSDL specification, mutual TLS requirements, and troubleshooting history.