One Person, Many Logins
Module 1 of 6 in the chapter Single Sign-On: The Browser Is the Broker, chapter 4 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: Why would a company put one system in charge of everyone’s login?
Every system has its own guard
Section titled “Every system has its own guard”Start with what you already know from the front door. When you log in to Salesforce, there are really two servers. One is the login server, the security guard, who checks who you are and gives you a wristband: your session. The other is the instance, your org, which only checks the wristband and serves your pages and your data.
Now add a second system. Say your company also has an HR system. It almost certainly has the same two pieces: its own security guard and its own resource. So for every system you use, there might be two servers. One is the resource. The other is the security guard.
One person, three names
Section titled “One person, three names”Meet Priya. She works in sales, and she uses three systems every day.
- In Salesforce, she’s
priya, with a password. - In the HR system, she’s
p.sharma, with a different password. - In the expense system, she’s
priya.s, with a third.
That’s normal. Each system was set up on its own, by different people, at different times, so the usernames don’t match and neither do the passwords. Logging in to just two of them means talking to four different servers: two guards, two resources. Priya’s browser is holding a session with each one.
What that costs
Section titled “What that costs”Three passwords doesn’t sound like much. Now make it ten, or twenty, which is closer to what most people have at work. What do people do with twenty passwords? They reuse them. They keep them simple. And they write them down.
I was on site at a client once, and I needed a keyboard. Someone handed me a spare one. I turned it over, and taped to the bottom was a piece of paper with a username and a password on it. That’s what too many passwords look like in real life.
There’s a second cost, and it’s less visible. Each system has its own rules: its own password length, its own lockout, its own way to reset a forgotten password, its own idea of MFA. If you have five or ten systems, one of them probably wasn’t built as carefully as the others. That one becomes the weak spot, and it holds the same person’s account as the strong ones.
The answer: one place to prove who you are
Section titled “The answer: one place to prove who you are”Single sign-on gives Priya one place to prove who she is. She signs in once, at a system whose whole job is checking who people are. That system is the identity provider, or IdP: it provides her identity to everyone else. Companies usually buy one built for it, such as Okta, Ping Identity or Microsoft Entra ID, or use Salesforce itself (chapter 7).
Every other system now trusts the identity provider instead of keeping its own password for Priya. Each one is a service provider, or SP: it provides a service, and leaves the login to the identity provider. Salesforce can be one. In Salesforce’s words, when you set it up this way, “authenticated users can flow from a third-party identity provider into Salesforce.”
The goal is a seamless day. Priya opens Salesforce, signs in at the identity provider, and she’s in. Later she clicks over to the HR system, and she’s in there too, without typing anything. That’s the “single” in single sign-on.
Why companies do it
Section titled “Why companies do it”Fewer passwords, so they can be stronger. One password instead of twenty means you can ask for a long, strong one, and people can actually remember it.
One place to enforce the rules. The identity provider applies the password policy, the IP restrictions and the MFA, for every system behind it, at the same high standard. A weaker system no longer drags the others down, because it doesn’t check passwords at all. One thing to remember from the front door: Salesforce still needs the identity provider to tell it how the person proved who they are, so that MFA counts (chapter 2, module 2).
One place to recover a password. Forgotten passwords are one of the most common help desk calls. With one identity provider, there’s one way to reset, not twenty.
Hiring and leaving. When someone joins, they get one account. When someone leaves, you switch them off once, at the identity provider, and they can’t sign in to any system behind it, instead of having to go into every one. Keeping each system’s own user records up to date is a separate job, called provisioning (chapter 12).
The catch
Section titled “The catch”There’s always a trade-off. One front door for everything means that door matters much more.
If the identity provider is down, nobody gets in anywhere. If it’s fooled, by a phishing page or a stolen password, every system behind it is open. So the identity provider deserves the strongest MFA you have, and phishing-resistant MFA for anyone who holds the keys (chapter 2, module 2). And you always keep a way back in for the people who fix things when it breaks. That’s module 5, and it’s one of my firm rules.
Watch it on video
Section titled “Watch it on video”In 2023 I made a short video on the concepts in this module and the next three: the identity provider, the service providers, the identity store, and the trust between them. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Look again at Priya’s picture with the identity provider in the middle. Who are the players, exactly? There’s Priya’s browser, the identity provider, the place it keeps passwords, and each service provider with its own two servers. Module 2 names them, and gives you one simple test for telling which one is the identity provider.
What an architect decides here
Section titled “What an architect decides here”- Which systems go behind the identity provider? Every system people sign in to should be a candidate. Know which ones can’t, and why.
- Who owns the identity provider? It’s now the most important system in the company for getting work done. It needs an owner, a support plan and its own security review.
- What happens on the day it’s down? Decide before it happens (module 5).
Explore
Section titled “Explore”- SAML SSO with Salesforce as the Service Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)