Log In, or Single Sign-On
Module 2 of 7 in the chapter SSO or OAuth? Choosing the Mechanism, chapter 5 of Securing Salesforce: Identity and Access. Each module stands on its own.
The question this module answers: When Priya uses Salesforce in her browser, when is it a plain login, when is it single sign-on, and why is it never OAuth?
The top row of the map
Section titled “The top row of the map”Start with the easiest row. A person, Priya, opens a browser and goes to Salesforce, and Salesforce draws her pages. She can be on a laptop, a phone or a tablet; it’s still a browser, and it’s still the same row.
She has two ways in.
- A direct login. Salesforce is the one that checks who she is: her Salesforce username, her password, her MFA. That’s the front door from chapter 2.
- Single sign-on. Her company has an identity provider (IdP), one system in charge of logins, and Salesforce trusts it. She signs in there once, and gets into Salesforce without signing in again. That’s chapter 4.
Which one is a question of how many systems she uses and who owns her login. It’s not a question of OAuth. In this row, there isn’t any.
Only arrows from the browser
Section titled “Only arrows from the browser”Here’s how I teach it on the whiteboard. I draw three boxes: Priya’s browser, a system A, and Salesforce. System A could be anything: an expense app, an HR system.
Priya goes to system A in her browser. Then she goes to Salesforce in her browser. Two arrows, both starting at the browser.
So what is this? What kind of authentication are we talking about? Browser to A, browser to Salesforce. There’s no OAuth here. She logs in to each one.
Now let me trick you. Call system A a service provider. Call Salesforce a second service provider. And all I do is add a box up here, and call it the identity provider. Now what kind of authentication is it?
It’s single sign-on. Priya signs in once, at the identity provider, and both service providers trust it. And look at the arrows. Every one of them still starts at the browser. That’s the test: if you have only arrows from the browser, you’re in the world of single sign-on.
That’s no accident. In chapter 4, the browser was the broker. The identity provider and Salesforce never call each other; the browser carries every message between them, by redirect. So in a single sign-on picture, every line runs to or from the browser.
Why there’s no OAuth in this row
Section titled “Why there’s no OAuth in this row”OAuth exists to let one piece of software reach Salesforce’s data for someone. In this row, no other software is reaching in. Salesforce draws its own pages, for the person in front of it, in her browser. The identity provider doesn’t fetch any data from Salesforce. It vouches for Priya, and Salesforce’s own login server gives her the session.
That’s why a team that wants “OAuth for our users” when they mean people working in Salesforce in a browser has picked the wrong word. What they want is single sign-on.
Login or single sign-on?
Section titled “Login or single sign-on?”So within this row, how do you choose? Chapter 4 gave the reasons. Single sign-on pays off when people use more than one system and the company wants one place for passwords, MFA and switching off a leaver. A direct login is fine for a small company with Salesforce and little else, or for the few admins who keep a back door.
And it’s rarely one or the other for a whole company. Staff may use single sign-on, while a partner without an identity system of its own gets Salesforce logins. It’s usually a blend, and Checkpoint 1 at the end of this chapter has you design one.
The line that changes everything
Section titled “The line that changes everything”Keep that whiteboard in your head, because in module 3 I’m going to draw one more line on it: from system A straight to Salesforce. One line between two servers, with no browser in it. That’s the moment OAuth comes in.
On the map
Section titled “On the map”Here’s where this module sits on the grid of every way to sign in (module 6 has the whole grid). Two sets: logging in to Salesforce, where Salesforce checks who you are, and single sign-on into Salesforce, where another system does. The blue cards you’ve met; the rest come later in the course.
What’s next
Section titled “What’s next”Module 3: a person through an app or another server, and the little line.
What an architect decides here
Section titled “What an architect decides here”- Who uses Salesforce in a browser, and through which door: a direct login or single sign-on.
- Which identity provider, for which group of people (chapter 4; chapter 6 sets it up).
- The test on every diagram: if every arrow starts at the browser, it’s single sign-on, and nobody needs OAuth for it.