Skip to content
SteveTechArcSteveTechArc Courses

The Mirror

Module 1 of 5 in the chapter The Mirror Image: Social Sign-On and Delegated Authentication, chapter 10 of Securing Salesforce: Identity and Access. Each module stands on its own.

The question this module answers: What is social sign-on, and why is it the web server flow you already know?

The flip, again

Section titled “The flip, again”

In chapter 9, Priya was at the Burger House. The Burger House was the app, Salesforce was the festival next door, and Priya signed in only at Salesforce. The Burger House got a code through her browser and swapped it for her wristband, server to server.

Now hold that picture up to a mirror.

Priya comes to a Salesforce site, say a customer community, and she doesn’t want another password. On the login page there’s a button: Log in with Google. She clicks it.

Who’s collecting her credentials now? Not Salesforce. Google is. Google has become the identity provider. And Salesforce? Salesforce is the Burger House. It’s the app that needs something from somewhere else: proof of who she is, and a little of her information.

That’s social sign-on. When a student asked me in class whether the Burger House was like social sign-on, the answer was: it’s exactly social sign-on. All we’ve done is reverse who’s who.

Five steps, in the mirror

Section titled “Five steps, in the mirror”

Here’s chapter 9’s picture again, in the same places. Only the names have moved.

The mirror: social sign-on Four lanes, the same as chapter 9's Burger House: Priya's browser; Salesforce, the app this time; Google's sign-in page; and Google's token endpoint and user info. Step 1: on Salesforce's login page, Priya clicks Log in with Google; Salesforce uses its auth provider and redirects her browser to Google. Step 2: the browser takes the authorize request to Google, where Priya signs in and consents; Google redirects her back with a code. Step 3: the browser brings the code to Salesforce's callback address; Salesforce has a short-lived code, not a token, and gives her a session after step 5. Step 4: Salesforce swaps the code with its key and secret at Google's token endpoint, server to server; the check passes and it gets an access token and an ID token. Step 5: Salesforce asks Google's user info who she is, with the access token, and gets only what she consented to share; then the registration handler decides which user she is. Footnote: chapter 9's web server flow with the names swapped; Google is the identity provider, Salesforce is the client. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-OFD-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} PRIYA'S BROWSER SALESFORCE: THE APP NOW GOOGLE: THE SIGN-IN PAGE GOOGLE: TOKEN AND USER INFO 1. Clicks Log in with Google on Salesforce's login page Uses the auth provider sends her browser to Google 2. Goes to Google redirected, with the request Google's sign-in Priya signs in and consents 3. Brings the code back to Salesforce's callback address Has the code a short-lived code, not a token 4. Swaps the code server to server: the back channel The token endpoint checks the code and Salesforce's key 5. Asks who she is then the registration handler: which user? The user info only what she consented to share the button redirect to Google the authorize request redirect + the code the code her session, after 5 code + key and secret access + ID token the access token her information Chapter 9's web server flow, with the names swapped: Google is the identity provider, Salesforce is the client. HOW TO READ IT Salesforce, in the app's lane this time the check passes © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge
  1. Priya clicks Log in with Google on Salesforce’s login page. Salesforce sends her browser to Google, with a request.
  2. She signs in at Google, and only there, and she consents. Google sends her back, not with a token, but with a code.
  3. Her browser brings the code to Salesforce, to Salesforce’s callback address.
  4. Salesforce swaps the code. It goes to Google’s token endpoint itself, server to server, with its own key and secret, and gets back tokens, “including an ID token” (S3).
  5. Salesforce asks who she is. With the access token, it calls Google for her information. Then Salesforce decides which Salesforce user she is, and she’s in.

Look at steps 2 to 4. It’s the same three moves as chapter 9: visit the login screen, come back with a code, swap the code for the tokens. The front channel carries only the code. The tokens come back on the back channel. Everything you learned about the web server flow still holds; you’ve just moved to the other side of the counter.

Section titled “The consent”

Step 2 has something you’ve probably clicked through a hundred times. Have you seen one of these? Google asks: do you consent to Salesforce seeing your name, your email address? You’ve seen the same screen when one app wants to read your mail in another.

It’s the same consent as chapter 9’s approval: “yes, the Burger House may fetch my drink.” Only now it’s Priya telling Google that Salesforce may have a little of her information. And it’s only what she agreed to. If she consented to her name and email, that’s what Salesforce gets, and only that.

Who’s the client?

Section titled “Who’s the client?”

Here’s a question I always ask the room. In steps 4 and 5, who is calling whom? Who’s asking for data, and who’s giving it?

Salesforce is the client, because it’s asking for the person’s information. Google is the server, because it’s giving it back.

That’s what makes social sign-on different from SAML. With SAML in chapters 4 and 6, the browser carried a signed assertion to Salesforce and Salesforce read it. Here, Salesforce makes a direct call to the provider, behind the scenes, to get her data. It’s a special case: Salesforce wants to talk to the social provider itself.

Then: who is she?

Section titled “Then: who is she?”

After step 5, Salesforce knows what Google says about her: an email address, a name, whatever she consented to share. It turns that into one shape, Auth.UserData, whatever the provider sent (S3).

But knowing her email isn’t the same as knowing which Salesforce user she is. Is she a customer you already have? Is she new? Should she be let in at all? That decision belongs to a piece of code, or a flow, that you write: the registration handler. It looks for a matching user, creates one if there isn’t one, or updates the one there is, and then she’s logged in (S3). Module 3 is about it.

Where you’ll see it

Section titled “Where you’ll see it”

Social sign-on is most likely on a community: an Experience Cloud site where customers or partners come in, and you’d rather not make them remember another password (S1). Module 4 is about where it fits, and where it doesn’t.

And notice, it’s not only Google. The same machinery reaches any provider that speaks OpenID Connect, including a company’s own identity provider, and even another Salesforce org. Module 2 shows the setup.

Three ways in

Section titled “Three ways in”

Put this beside chapters 4 and 6, and you have the three single sign-on flows into Salesforce:

  • SP-initiated SAML: Priya starts at Salesforce, gets sent to the identity provider, and comes back with an assertion.
  • IdP-initiated SAML: she starts at the identity provider and shows up at Salesforce with the assertion already in hand.
  • Social sign-on, and OpenID Connect: she starts at Salesforce, gets sent to the provider, comes back with a code, and Salesforce does the rest server to server.

Get these three, and single sign-on stops being a mystery. It’s just things being passed back and forth, and you know who passes what.

Test knowledge. In my experience, know who’s who in social sign-on: the social provider is the identity provider, and Salesforce is the client that asks for the person’s information.

What’s next

Section titled “What’s next”

Module 2: where it’s set up. The auth provider.

What an architect decides here

Section titled “What an architect decides here”
  • Whether a group of users should sign in with an outside identity, and which one.
  • What information Salesforce asks for, and so what the person is asked to consent to.
  • Who decides which user she becomes: the registration handler, module 3.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.