SAML is a federated, industry standard web single sign-on approach that works through browser-based authentication. Delegated authentication is proprietary to Salesforce and can control user access at the profile level, including client applications. The practical difference is scope and control: SAML supplements Salesforce login, while delegated authentication can replace the password check for more access paths.
Why This Matters for Security Teams
For Salesforce deployments, the SAML versus delegated authentication choice is not just a login preference. It changes where trust is enforced, which clients are covered, and how much control the organisation retains over password checks and session handling. SAML is a browser-based federation pattern, while delegated authentication shifts the password decision back to Salesforce’s configured authentication flow. That matters when teams need consistent policy enforcement across users, profiles, and application paths.
The risk is not theoretical. Identity incidents often start with misunderstood trust boundaries, especially when organisations assume one mechanism protects every access path. NHI Mgmt Group has found that only 5.7% of organisations have full visibility into their service accounts, which is a useful reminder that identity scope is frequently broader than teams expect. The same discipline applies here: understand which login path is actually being controlled, not just which one was documented.
Practitioners often discover these gaps only after a client app or legacy access path bypasses the control they thought was universal, rather than through intentional access-path testing.
How It Works in Practice
SAML single sign-on is the standard choice when Salesforce should trust an external identity provider to authenticate the user before Salesforce grants access. In practice, the user is redirected to the IdP, the IdP asserts identity, and Salesforce accepts that assertion for the web session. This is strong for centralised authentication, especially where the organisation already uses a mature IdP and wants one policy plane for workforce access.
Delegated authentication is different. Salesforce remains the place where the authentication request is initiated, but it calls out to an external web service to validate the password. That makes it more proprietary and more tightly tied to Salesforce-specific configuration. It can be applied at the profile level and may affect more access paths than browser SSO alone, which is why teams sometimes use it when they need finer-grained control over specific user populations.
- SAML is better when the goal is federated login, central MFA, and a standard web SSO flow.
- Delegated authentication is better when Salesforce-specific password validation must be retained for selected profiles.
- SAML reduces direct password handling inside Salesforce; delegated authentication still depends on a password-validation callback.
- Both require careful testing for provisioning, session timeout, and fallback behaviour.
Security teams should map each access path separately: browser login, mobile access, API-connected tools, and legacy clients. If the organisation uses broader identity governance, use that to verify whether Salesforce is the only relying party or just one of several systems in scope. The practical test is whether the control survives real user journeys, not just the main portal flow. For broader identity risk context, see the Ultimate Guide to NHIs — What are Non-Human Identities and the current control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls.
These controls tend to break down when Salesforce is integrated with legacy clients or mixed authentication paths because the implemented login flow no longer matches the documented one.
Common Variations and Edge Cases
Tighter authentication control often increases configuration and support overhead, requiring organisations to balance central policy enforcement against legacy compatibility. That tradeoff is especially visible in Salesforce estates that mix browser users, API integrations, and older desktop or mobile clients.
One common edge case is profile-level delegation. Teams may assume delegated authentication affects everyone equally, but Salesforce can apply it selectively. That makes it useful for phased rollouts, yet it also creates inconsistent user experience if security and IT do not keep profile assignments aligned with business roles. Another variation is coexistence: some organisations use SAML for workforce SSO while retaining delegated authentication for a subset of users or fallback scenarios. Current guidance suggests documenting those exceptions explicitly, because hidden exceptions become audit gaps.
Another practical issue is password lifecycle ownership. With SAML, the IdP owns primary authentication; with delegated authentication, the external validation service still receives the password check. That means incident response, recovery, and deprovisioning processes must be clear about which system is authoritative. The difference matters when access is being revoked quickly or when a service outage affects sign-in. For an example of how identity and token trust can fail in practice, the Salesloft OAuth token breach shows how access can persist through non-password pathways, while the Klue OAuth Supply Chain Breach reinforces the need to test connected access paths, not just interactive login.
There is no universal standard for this yet across all Salesforce deployment patterns, so the safest approach is to validate the exact login journey, profile mapping, and exception handling in pre-production before relying on either method as the primary control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity proofing and access control map to the Salesforce login decision point. |
| NIST SP 800-63 | Federation | SAML is a federation pattern covered by digital identity guidance. |
| NIST Zero Trust (SP 800-207) | PL-3 | Different access paths need explicit trust boundaries and policy enforcement. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Salesforce-connected credentials and tokens are non-human access assets that need governance. |
| NIST AI RMF | Authentication design must support governance, accountability, and reliability. |
Use federation requirements to validate assertions, session trust, and authentication assurance.
Related resources from NHI Mgmt Group
- What is the difference between identity governance and single sign-on in an IAM programme?
- What is the difference between MFA and single sign-on for reducing authentication risk?
- What is the difference between passwordless authentication and single sign-on for frontline access?
- When should organisations prioritise OIDC over SAML for single sign-on?
