Skip to content
SteveTechArcSteveTechArc Courses

The Mirror Image: Social Sign-On and Delegated Authentication

Chapter 10 of Securing Salesforce: Identity and Access, Part 2: Accepting and Providing Identity. Start with chapter 9 if the Burger House and the web server flow are new to you.

Chapter 9 had Priya at the Burger House: an app that sent her to Salesforce, got a code back, and swapped it for her wristband. Now hold that picture up to a mirror. Priya comes to a Salesforce site and clicks Log in with Google. Google collects her password now, and Salesforce is the app.

That’s social sign-on, and it’s the first of this chapter’s other front doors into Salesforce. The second is much older: delegated authentication, for when the passwords live in a system that can’t speak SAML or OpenID Connect.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • Social sign-on is the web server flow, reversed: the social provider is the identity provider, and Salesforce is the client that asks for her information.
  • The auth provider is where it’s set up: a ready-made type, OpenID Connect for any provider that speaks it, or a custom one in Apex. Not every type does single sign-on.
  • Between two Salesforce orgs, the Salesforce type, with an external client app in the identity provider org.
  • The registration handler decides which Salesforce user she becomes: createUser the first time, updateUser every time after.
  • Salesforce doesn’t validate the ID token for the handler. Check a claim before you trust it.
  • Social sign-on is for customers and partners, not staff, and a social login proves she controls that account, not who she is.
  • Delegated authentication: Salesforce’s own login page asks your service true or false. It doesn’t meet the MFA requirement, and it locks out everyone on it if your service goes down.

The picture

Section titled “The picture”

Here’s the chapter’s picture: chapter 9’s Burger House, in the same places, with the names swapped.

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

The path through this chapter

Section titled “The path through this chapter”

Five modules, each standing on its own, and a practice.

  1. The Mirror The flip, again; five steps in the mirror; the consent; who’s the client; then, who is she; three ways in.
  2. Auth Providers A ready-made list; the pieces; the button; any OpenID Connect provider; between two Salesforce orgs.
  3. The Registration Handler What arrives; two methods; the user it runs as; the checks; the ID token; Apex or Flow; a skeleton.
  4. Where It Fits Most likely, a community; three groups, three doors; what a social login proves; the second job; Steve Trucking’s recipients.
  5. Delegated Authentication The legacy store; teach it SAML first; true or false; setting it up; what you give up; don’t lock yourself out.

Then the practice: one lab org logging in through the other, with an auth provider and your own registration handler.

Check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • Which front door each group of people uses, by who manages them.
  • Which auth provider type, and whether it does single sign-on at all.
  • Who the registration handler lets in, how it matches people, and what it trusts.
  • PKCE and MFA on every auth provider.
  • Whether a legacy store can learn SAML or OpenID Connect before you reach for delegated authentication, and who never gets it: the admins.

Beyond the exam: what AI changes. A customer’s agent that signs her in with a social identity is still her identity, with only what she consented to share. Chapter 17 takes it further.

Explore

Section titled “Explore”

Each module lists its own sources, each checked 2026-11-07. Two to start with:

Next: Acting as Someone: The Impersonation Flows.

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.