Auth Providers
Module 2 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: Where is social sign-on set up in Salesforce, and how does the same setup reach a company’s own identity provider?
One setup, many front doors
Section titled “One setup, many front doors”Module 1 showed the mirror: Salesforce sends Priya to another provider, gets a code back, and swaps it. The thing in Salesforce that knows how to do that is the auth provider, short for authentication provider. In Setup it’s called Auth. Providers.
An auth provider lets people log in to your org, or to an Experience Cloud site, “using credentials from a third party” (S1). Most of them do a second job too: they let Salesforce reach the person’s data at that third party, with her permission (S1). It’s available in Enterprise, Performance, Unlimited and Developer editions, and you need Customize Application and Manage Auth. Providers to set one up (S1).
A ready-made list
Section titled “A ready-made list”When you create one, the first thing you pick is its type. Salesforce has a nice list of ready-made ones (S2):
Apple, Bitbucket, Concur, Facebook, GitHub, Google, Janrain, LinkedIn, Microsoft, Microsoft Access Control Service, MuleSoft, OpenID Connect, Salesforce, Slack, and X.
Each ready-made type already knows where its provider’s login page and token endpoint are, so there’s less to fill in. In my video on Google, the only thing I had to set was the name.
Here’s the catch: not every type does both jobs. GitHub and Microsoft Access Control Service give third-party data access but don’t support single sign-on; X supports single sign-on but not third-party data access (S2). So if the goal is a login button, check the type first.
And if your provider isn’t on the list? Two ways out. OpenID Connect “supports any third party that uses the OpenID Connect protocol” (S2). And for a provider that doesn’t speak OpenID Connect, you can write a custom auth provider in Apex, which uses OAuth 2.0 (S2). Some apps just aren’t out of the box, so you build your own.
The pieces
Section titled “The pieces”Whatever the type, the setup has two sides, and you go back and forth between them.
- At the provider, register an app for Salesforce. That gives you a client ID and a client secret: Salesforce’s own business license at that provider, the same idea as the Burger House’s in chapter 9.
- In Salesforce, create the auth provider: its type, a name, a URL suffix, and the key and secret from step 1. The URL suffix becomes part of the addresses Salesforce generates for it, such as
/services/auth/sso/YourSuffix(S5). - Choose the registration handler, and the user it runs as. Module 3.
- Copy the callback URL back. When you save, Salesforce shows the auth provider’s client configuration URLs. The callback URL goes back into the provider’s app from step 1 (S5). That’s where Google, or whoever, sends Priya with her code. Chapter 9’s rule still holds: the callback address has to match.
- Test it, with the test-only initialization URL Salesforce gives you (S5).
- Put the button on the login page.
Two settings on the auth provider are worth knowing. Use Proof Key for Code Exchange (PKCE) Extension turns on chapter 9’s pickup word for this flow (S5, S6): Salesforce is the app now, so it’s Salesforce writing the slip. And Use Salesforce MFA for this SSO provider asks for Salesforce’s multi-factor authentication instead of the provider’s, for the users who have MFA applied to them directly (S5).
The button
Section titled “The button”Where does the button show up? It depends on the login page.
On an Experience Cloud site’s login page, the auth provider’s Icon URL becomes a button. That icon applies to a site only; Salesforce is plain about it: “It doesn’t appear on your Salesforce login page or My Domain login URL” (S5). For the org’s own login page, you add the auth provider in My Domain, which is what I did in the video: have My Domain, add the auth provider there, and it appears on the screen. In My Domain’s settings, it’s under Authentication Configuration, as an authentication service.
Any OpenID Connect provider
Section titled “Any OpenID Connect provider”Most companies already have an identity provider for their staff: chapter 6 connected one with SAML. If it speaks OpenID Connect, the same auth provider machinery reaches it. That’s the third way in, beside SAML.
You register a web app with the provider, then create an auth provider of type OpenID Connect and fill in what the ready-made types fill in for you: the authorize endpoint, the token endpoint, and the user info endpoint (S6). Salesforce’s own examples of OpenID providers are Amazon, Google and PayPal (S6).
There’s an optional Token Issuer field. Here’s a fact to know, in Salesforce’s words: “The ID token is validated against the Token Issuer value and information in the UserInfo endpoint. The signature of the ID token isn’t validated” (S6). Hold on to that; it matters in module 3.
Between two Salesforce orgs
Section titled “Between two Salesforce orgs”And the provider can be another Salesforce org. That has its own type, Salesforce, “to set up single sign-on (SSO) between two Salesforce orgs” (S5). One org is the identity provider; the other, the relying party, lets its users log in with the first org’s credentials.
It’s the same pieces, with Salesforce on both sides (S5):
- In the identity provider org, create an external client app, the kind from chapter 7. Its consumer key and secret are the provider’s app from step 1.
- In the relying party org, create an auth provider of type Salesforce, with that key and secret.
- Back in the identity provider org, paste the auth provider’s callback URL into the external client app.
Underneath, it’s chapter 9’s web server flow, with openid: the identity provider org’s login page, a code, the swap. For a sandbox, Salesforce offers a Salesforce-managed app so you can skip some steps, but “The Salesforce-managed app can experience downtime and isn’t recommended for production” (S5). In production, use your own external client app.
This is the practice for this chapter: your two lab orgs, one signing in through the other.
Test knowledge. In my experience, know that social sign-on is set up with an auth provider, that Salesforce has ready-made types for common providers, OpenID Connect for any provider that speaks it, and a custom Apex provider for the rest.
Watch it on video
Section titled “Watch it on video”In 2023 I made a video setting up Google as an auth provider in Salesforce, with a registration handler and the button on the login page. The note under the video says what’s still right and what’s changed since.
What’s next
Section titled “What’s next”Module 3: when Priya arrives, which Salesforce user does she become? The registration handler.
What an architect decides here
Section titled “What an architect decides here”- Which type: a ready-made one, OpenID Connect, or a custom Apex provider; and whether it does single sign-on at all.
- Which login page gets the button: an Experience Cloud site, the org’s own, or both.
- PKCE and MFA: on for each auth provider, and whose MFA counts.
- Your own external client app in production, never the Salesforce-managed one.
Explore
Section titled “Explore”- Define an Authentication Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Configure a Salesforce Authentication Provider (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)
- Configure an Authentication Provider Using OpenID Connect (opens in a new tab) (Salesforce Help, Winter ‘27; checked 2026-11-07)