Choosing the Identity Provider

Module 6 of 6 in the chapter Salesforce as the Identity Provider, chapter 7 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: Salesforce, Microsoft Entra ID, Okta: who should vouch for whom?

The question I always get

Once people have built the dance, they ask the obvious question. Salesforce can be an identity provider. So should it be ours? Or should we use Okta, or Entra ID, or whatever we’ve got?

My answer starts with a question back: does the customer already have one? If the company already runs Okta or Entra ID, and everyone signs in to it every morning, then you should use it. Salesforce becomes another service provider behind it, as in chapter 6.

Why? Because the identity provider should be the system that already knows the people. It’s where their password and MFA live, where they’re added when they join, and where they’re switched off when they leave. Put a second identity provider beside it for the same people, and you’ve got two places to switch someone off, and one day someone will be missed.

It’s usually a blend

But that answer is only for one group of people. A company doesn’t have one group. Here’s what I see in most projects.

• Staff sign in through the company’s identity provider: the internal Okta, the Entra ID.
• Admins keep their direct Salesforce login, with MFA, as the backup plan: the back door from chapter 4, module 5.
• Partners and customers, the people on an Experience Cloud site, either have Salesforce logins on the site, or you decide whether to let them use a social sign-on, like a Google account (chapter 10).

So it’s usually a blend. There’s never one way. There’s usually three or four ways of signing in to Salesforce, and that’s normal. The architect’s job isn’t to pick one identity provider. It’s to pick the right one for each group, and to know where each line goes.

Four questions for each group

When I’m deciding who should vouch for a group of people, these are the questions I ask.

1. Who already knows them? Where are their accounts today? That system is usually the right identity provider. Don’t make people a second password if a first one already works.
2. Who switches them off? When someone leaves, which system does the business change first? The identity provider should be that system, so leaving is one switch.
3. What else do they need to reach? If it’s only Salesforce, Salesforce’s own logins can do it. If it’s Salesforce and five other apps, the identity provider should be the one that can vouch into all of them.
4. What does it send? Can the identity provider sign both the response and the assertion, with SHA-256, and tell Salesforce how the person signed in, with MFA (chapter 6, module 4)? If not, that’s a conversation before you choose it, not after.

Where Salesforce vouches

Look at the third question again. That’s where Salesforce as the identity provider earns its place. When Salesforce is the system that already knows the people, and they need something beyond Salesforce, Salesforce can vouch for them onward.

• Other orgs. Your production org vouches for the other orgs your people work in (module 1).
• People who live on a site. Partners and customers with Salesforce logins on an Experience Cloud site, who need another app too (module 5, and chapter 14).
• A company with nothing else. A small company that runs on Salesforce, with a few other apps and no identity provider of its own.

And where Salesforce shouldn’t vouch: for staff who already sign in to a corporate identity provider every morning. They have one already.

Steve Trucking, from the identity provider’s seat

In chapter 5’s checkpoint, you chose a door for each group at Steve Trucking. Now ask the question from this chapter’s seat: who vouches for each group?

Click to enlarge

Staff: Entra ID. It came with the company’s Microsoft 365, and everyone signs in to email with it. Entra ID already knows them and already switches them off. Salesforce is a service provider behind it (chapter 6).

Two admins: Salesforce itself. A local login with MFA, never on single sign-on. If Entra ID has a bad day, they can still get in and fix it.

Retail Partner users: their own identity provider. Each big retailer brings its own, and the partner site trusts each one separately. Steve Trucking doesn’t vouch for another company’s staff; their own company does (chapters 10 and 14).

Small carriers: Salesforce. Most of them have no identity system at all. Some are a family and three trucks. Salesforce knows them, through their logins on the partner site, and nobody else does (chapter 14).

That’s four groups and four identity providers, and Salesforce is one of them. Count Steve Trucking’s crews, recipients and services from chapter 5 too, and you’ll see why I say there are usually three or four ways, or more.

What if the carriers also needed another app, a tool for planning their loads, say, that isn’t Salesforce? Look at the four questions. Who already knows them? Salesforce. Who switches them off? Salesforce, when a carrier’s login is removed from the site. So Salesforce would vouch for them, as the identity provider, into that app, with SAML or OpenID Connect, whichever the app speaks (module 5). That’s the amber card: a “what if”, not part of the story.

One identity provider behind another

One more pattern you’ll meet. Staff sign in at Entra ID, which vouches for them into Salesforce. Then Salesforce, as an identity provider, vouches for them into a third app. A chain: Entra ID, then Salesforce, then the app.

My rule: don’t chain it. Register the third app with the company’s identity provider directly. Go back to the four questions. Who already knows these people? Entra ID. Who switches them off? Entra ID. So Entra ID should vouch for them into every app they use, and Salesforce stays one of those apps, a service provider beside the third app, not in front of it. One identity provider for staff, and one place to switch them off.

Salesforce vouches onward for the people only Salesforce knows, like the carriers above. For staff, the company’s identity provider already does the job.

The end of the build

You’ve now seen Salesforce in both seats: the service provider in chapter 6, the identity provider here. The other app trusts Salesforce, Salesforce holds the private key and signs, and the Federation ID links the two Priyas. And you know when to put Salesforce in that seat, and when to leave it where it is.

The next chapters move from single sign-on to OAuth: how an app, not a browser, gets to Salesforce data. Chapter 8 starts with the base pattern at a food festival.

What an architect decides here

• The identity provider for each group of people, using what the customer already has.
• The back door: who keeps a direct login, and how it’s protected.
• Where Salesforce vouches onward, and for whom.
• One place to switch each person off, written down for each group.

Explore

• Salesforce as an Identity Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)