Where It Fits

Module 4 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: Who should sign in to Salesforce with a social identity, and who shouldn’t?

Most likely, a community

Think about who comes to an Experience Cloud site. A customer checking an order. A member of a club. Someone following a delivery. Do they want another password? A Salesforce password, a password for this site, a password for that site? They do not.

That’s where social sign-on earns its place. Most likely, you’ll use it on a community: let some of those people log in with an account they already have. It’s nice for them, because they don’t have to remember an extra password. And a little of who they are at that provider comes across, so you don’t have to ask for it again.

Three groups, three doors

But not everyone who signs in to Salesforce is a customer. Ask one question about each group: who manages these people? Who adds them, and who removes them?

Click to enlarge

Staff. The company hires them and the company removes them. They come in through the company’s identity provider, with SAML or OpenID Connect, chapter 6. Why not let staff use a social login? Because when someone leaves, you switch off one account at the identity provider, and they’re out of everything. A personal Google account doesn’t leave the company with them. And their multi-factor authentication is set by the company, not by them.

Customers. Nobody manages them but themselves. That’s who social sign-on is for: on the site’s login page, beside the site’s own login and maybe self-registration, a button for each provider you offer (S5). An option, not the only way in.

A partner’s people. Another company manages them. If that company has its own identity provider, let its people come in through it: an auth provider with OpenID Connect (module 2), or SAML. Then when someone leaves the partner, the partner switches them off, and you don’t have to know. Chapter 14 builds partner and customer sites in depth.

What a social login proves

Here’s the part people skip. What does it actually mean when Priya signs in with Google?

It means Google says she controls that Google account, right now. That’s all. It doesn’t prove her name is Priya. It doesn’t prove she’s your customer. It doesn’t even prove her email address belongs to her, unless the provider says it checked it; some providers send a field for that, like the email_verified in Salesforce’s own user info example (S4).

So a social login is good for “it’s the same person as last time.” It’s not good on its own for “she’s allowed to see this account’s orders.” That’s why the registration handler’s checks in module 3 matter, and why some things should still ask for more: a step-up, or a link to a record you can prove is hers.

The second job

Module 2 said most auth providers do two jobs (S1). The first is the login. The second is reaching her data at the provider, with her permission: Salesforce can keep the provider’s access token for her, and your Apex can get it with the Auth.AuthToken class (S4). Say she consents to share her calendar, and your site shows her bookings beside it.

That’s useful, and it’s also more to protect. Ask for the login, and only ask for her data if you’ll use it. What she’s asked to consent to should match what you need.

Steve Trucking: the recipients

Steve Trucking is a regional delivery company that delivers goods for large retailers. The people receiving those deliveries want to know when the truck is coming. Do they need an account at all?

Most don’t. By default, a recipient gets a tracking link for that one delivery, and no login at all. For the ones who want more, say to see every delivery they’ve had, or to reschedule, social sign-on is an option: no new password, and a registration handler that only creates a user when there’s a delivery to match her to.

Staff at Steve Trucking come in through the company’s identity provider. Retail Partners, big retailers with their own identity providers, bring their own. Small carriers with no identity system at all get Salesforce logins on the partner site. Three groups, three doors. Checkpoint 1 put it together; the capstone comes back to it.

Test knowledge. In my experience, know that social sign-on is most likely used for customers on an Experience Cloud site, and that staff come in through the company’s identity provider.

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.

What’s next

Module 5: the old-school door. Delegated authentication.

What an architect decides here

• Who manages each group of people, and so which front door each one uses.
• Which providers to offer customers, and whether social sign-on is an option or the only way in.
• What a social login is trusted for, and what still needs more proof.
• Whether to ask for her data at the provider, or only for the login.

Explore

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