Salesforce in the Middle: One Login, Many Applications
- Vítor Batista @asUgo
- 3 days ago
- 4 min read
Picture this: you arrive at a hotel, show your ID at the front desk, and walk away with a keycard that opens your room, the gym, the pool, and the parking garage. You handed your ID to one person. That one person verified who you are and then unlocked everything else. You did not show your ID to the gym attendant, the pool manager, or the parking booth separately.
This is essentially what Salesforce can do in an identity architecture: act as the front desk for your authentication chain.
Most people know Salesforce as a destination, a place users log into. What is less obvious is that Salesforce can also be the system that vouches for those users to other applications. In other words, Salesforce can be a Service Provider (SP) and an Identity Provider (IdP) at the same time.
What Does That Actually Mean?
When Salesforce acts as a Service Provider, it is the destination. An external identity system, such as Okta, Azure AD, or another Salesforce org, tells Salesforce "this user is verified," and Salesforce lets them in. Salesforce trusts that external assertion.
When Salesforce acts as an Identity Provider, the roles flip. Salesforce is now the one making the call. It tells downstream apps and orgs "this user is who they say they are," and those systems trust Salesforce's word.
The interesting architecture is when Salesforce does both in the same flow.
The IdP Chain
Think back to the hotel analogy. The front desk (Salesforce) did not create your ID. Someone else, your home government, issued it. The front desk verified that external credential and then issued its own keycard. Guests do not carry their passport into the gym. The keycard is all they need.
An IdP chain works the same way.
Your user authenticates through an upstream identity system (the government that issued the ID).
Salesforce sits in the middle: it receives that authentication as a Service Provider, verifies it, and then acts as the Identity Provider for everything downstream.
Downstream apps and orgs receive Salesforce's assertion (the keycard). In this model, they authenticate against Salesforce, not against the original identity source.
The result is one login experience and a centralized federation point, even when the authoritative identity source remains upstream.
SAML SSO Across Orgs and Experience Cloud Sites
For organizations running multiple Salesforce orgs, one org can be configured as the IdP and the others as Service Providers. A user logs in once through the IdP org, and that authentication flows to the SP orgs through a signed SAML assertion.
This is a hub-and-spoke model. The IdP org is the hub. The SP orgs are the spokes. Each spoke trusts the hub's assertion instead of managing its own authentication.
If your setup includes Experience Cloud Sites rather than standard orgs, the underlying logic is the same. The adjustment is in the endpoint URLs: each Experience Cloud site uses its own unique login and logout endpoints rather than the standard org login URL. Your SAML configuration needs to point to those site-specific endpoints. The trust model does not change; only the destination address does.
Salesforce as an OpenID Connect Provider
Salesforce also supports acting as an OpenID Connect (OIDC) provider. In this mode, downstream relying parties, including custom applications and, in some scenarios, other Salesforce orgs, can authenticate their users through Salesforce. The relying party receives standard OIDC tokens from Salesforce after the user authenticates.
This opens up federated login scenarios where authentication management is centralized. Authentication is delegated to Salesforce, although user provisioning and account records may still exist in downstream systems.
One detail worth calling out: when Salesforce vouches for a user downstream, the target system still needs a user record to map that identity to. Just-in-Time (JIT) provisioning addresses this by creating or updating that account on first login from the assertion, while other setups rely on SCIM or API-based provisioning to keep those records in sync.
Mixing Protocols
Salesforce supports both SAML and OIDC on the SP side and the IdP side. That means you are not locked into a single protocol across your architecture.
You could configure an OIDC Authentication Provider for how users log into Salesforce, while Salesforce issues SAML assertions to your downstream service providers. The choice of protocol on each leg of the chain can follow the requirements of each connected system.
Why This Matters for Your Architecture
For decision-makers, the practical value comes down to three things:
Centralized authentication. You can reduce the number of separate authentication integrations you manage across your Salesforce-connected apps and orgs. Salesforce can serve as a central federation layer within a Salesforce-centric ecosystem.
Flexibility across Salesforce environments. Whether you are connecting multiple orgs, Experience Cloud sites, or third-party applications, the same identity model applies. The endpoint details vary; the architecture does not.
Protocol coverage. SAML and OIDC are the two dominant protocols in enterprise identity. Salesforce supporting both on both sides of a flow means fewer constraints when integrating with systems that are not built on Salesforce.
Final Thoughts
Most organizations deploy Salesforce as a destination and never think about its identity capabilities. That is leaving functionality on the table.
When you position Salesforce as the front desk of your authentication chain, you gain a centralized control point for who gets in, where they get in, and through which door. That conversation is worth having before you add the next org, the next site, or the next third-party integration.
Connect with me on LinkedIn to share ideas or provide feedback Vítor Batista | LinkedIn
Comments