Auth. Providers
Auth Providers is the Salesforce Setup page where administrators configure external identity providers (Google, Facebook, LinkedIn, Microsoft, Apple, Twitter, OpenID Connect, GitHub, custom) that users can authenticate against to log into Salesforce or into Experience Cloud sites.
Definition
Auth Providers is the Salesforce Setup page where administrators configure external identity providers (Google, Facebook, LinkedIn, Microsoft, Apple, Twitter, OpenID Connect, GitHub, custom) that users can authenticate against to log into Salesforce or into Experience Cloud sites. Each Auth Provider record holds the OAuth client ID, client secret, authorization endpoint, token endpoint, and the scopes Salesforce requests from the external provider. Once configured, the provider appears as a Login With button on the Salesforce login page or the Experience Cloud login page.
Auth Providers are the foundation for social sign-in and federated SSO scenarios. They are different from SAML SSO (configured under Single Sign-On Settings) which uses SAML assertions rather than OAuth tokens. Auth Providers are the right choice for OAuth-based identity (Google, Microsoft Entra OAuth, custom OpenID Connect IdPs); SAML is the right choice for traditional enterprise SSO (Okta, Microsoft Entra SAML, Ping). Most enterprise orgs use both, with Auth Providers for customer-facing Experience Cloud login and SAML for internal Salesforce user login.
Why Auth Providers and SAML SSO live in different parts of Setup
Where Auth Providers lives in setup
Setup, Identity, Auth. Providers (note the period in the navigation label). The page lists every configured Auth Provider in the org, the provider type (Google, Facebook, OpenID Connect, etc.), the consumer key and secret (masked), and the callback URL Salesforce expects the IdP to redirect to. Click into a provider to edit its registration handler (the Apex class that processes the OAuth callback) or to copy the callback URL for registering the OAuth client at the IdP side.
Provider types and what each is for
Salesforce ships pre-built Auth Provider types for Google, Facebook, LinkedIn, Microsoft, Apple, Twitter, GitHub, Slack, and Open OpenID Connect. Each type pre-fills the authorization and token endpoints for that provider so admins only need to supply the client ID and secret. The OpenID Connect type is the generic option for any IdP that supports the OpenID Connect protocol (Okta, Microsoft Entra OAuth, Auth0, custom IdPs). Use the named types for the named providers and OpenID Connect for everything else.
Registration Handler and the user-create decision
When a user logs in through an Auth Provider for the first time, Salesforce calls the Registration Handler (an Apex class implementing Auth.RegistrationHandler) to decide what to do: create a new user, match to an existing user, reject the login. The handler receives the OAuth user profile from the IdP and the org's Salesforce metadata, and returns a User record. For Experience Cloud sites, the default handler usually creates Customer Community users. For internal Salesforce login, the handler typically matches to existing internal users by email and rejects unknown emails. The handler is the most consequential part of the Auth Provider configuration; getting it wrong creates duplicate users or grants login to unintended users.
Scopes and what data Salesforce receives
Scopes are the OAuth permission strings Salesforce requests from the IdP. Common scopes: openid, profile, email. Provider-specific scopes can request additional data (Google's user.read for full profile, Microsoft's User.Read for graph API access). Salesforce uses the scopes to populate the User record in the Registration Handler; without the right scopes, the handler may receive a username and email but not the user's name or photo. Most orgs request the minimum scopes needed and avoid scopes that pull data the org has no use for; over-requesting scopes is a security review red flag in B2B contexts.
Callback URLs and the IdP registration step
Every Auth Provider has a callback URL that the IdP must redirect to after authentication. Salesforce generates this URL automatically when the provider is created. The admin must copy this URL into the OAuth client configuration on the IdP side; without the IdP knowing the callback URL, the OAuth flow fails at the redirect step. The callback URL is environment-specific (sandbox callback differs from production callback), so each environment needs its own OAuth client at the IdP. This is one of the most common Auth Provider setup mistakes; admins configure for production and then puzzle why the sandbox flow does not work.
Auth Providers vs SAML SSO
Auth Providers use OAuth 2.0 and OpenID Connect; SAML SSO uses SAML 2.0. Both achieve federated login but the protocols differ. SAML predates OAuth in enterprise SSO; many enterprise IdPs (Okta, Ping, Microsoft Entra) support both. The decision is usually driven by use case: OAuth for consumer-facing flows (social login, mobile apps), SAML for enterprise internal-user login. SAML is configured in a different Setup area (Single Sign-On Settings), and the two configurations are independent; an org can have both active simultaneously for different user populations.
Permissions, license consumption, and Experience Cloud usage
Auth Provider login can produce internal user logins (consuming internal licenses) or external user logins (Customer Community, Partner Community, External Identity license). The Registration Handler controls which type of user gets created, which controls which license is consumed. For high-volume Experience Cloud scenarios (thousands of customer logins), the External Identity license is the right choice; for low-volume internal user federation, the standard internal user license applies. Misconfiguration here creates surprise license consumption that surfaces in the next quarterly Salesforce invoice.
How to set up an Auth Provider end to end
The setup is sequential: create the Auth Provider in Salesforce, copy the callback URL to the IdP, configure the OAuth client at the IdP, copy the client ID and secret back to Salesforce, write or pick the Registration Handler, test. Each step depends on the previous; skipping a step produces an opaque failure at runtime.
- Pick the provider type
Setup, Auth. Providers, New. Pick from the pre-built list (Google, Facebook, Microsoft) or OpenID Connect for anything else. The choice pre-fills the authorization and token endpoints.
- Save the provider to get the callback URL
Save with placeholder client ID and secret. The Salesforce-generated callback URL appears in the saved record. Copy this URL.
- Register an OAuth client at the IdP using the callback URL
Open the IdP admin console (Google Cloud Console, Microsoft Entra, Okta admin, etc.). Create a new OAuth client. Paste the Salesforce callback URL as the authorized redirect URI.
- Copy the IdP client ID and client secret back to Salesforce
Edit the Salesforce Auth Provider record. Paste the IdP client ID and client secret. Configure the OAuth scopes you need.
- Write or pick the Registration Handler
Default Registration Handler creates Customer Community users for Experience Cloud. For internal users, write a custom handler that matches by email to existing users and rejects unknown emails.
- Test the flow in a sandbox or with a test user
Hit the Test-Only Initialization URL from the Auth Provider record. Walk the OAuth flow. Confirm the user is created or matched as expected.
- Expose the Login With button on Salesforce or Experience Cloud login
For internal Salesforce login: Setup, Identity, My Domain, Authentication Configuration. For Experience Cloud: site Login & Registration page settings. Toggle the Auth Provider as a login option.
Google, Facebook, LinkedIn, Microsoft, Apple, Twitter, GitHub, Slack, or OpenID Connect. Pick the named type when possible.
Credentials obtained from registering an OAuth client at the IdP. Stored encrypted in the Auth Provider record.
Apex class that decides user-create vs match vs reject for new logins. The most consequential configuration on the record.
OAuth permission strings Salesforce requests from the IdP. Request the minimum needed.
Whether the Auth Provider appears on internal Salesforce login, Experience Cloud login, or both.
- Sandbox callback URLs differ from production. Each environment needs its own OAuth client at the IdP; configuring only for production leaves sandbox flows broken.
- The Registration Handler is the single most consequential part of the setup. A handler that creates users without matching to existing ones produces duplicate users; a handler that rejects unknown emails locks out legitimate first-time logins.
- License consumption depends on what type of user the handler creates. Internal user creation consumes internal licenses; external user creation consumes External Identity or Community licenses. Plan accordingly.
- Over-requesting scopes is a security review red flag in B2B contexts. Request the minimum scopes the org actually uses.
- Auth Providers and SAML SSO are configured in different Setup areas. An org running both for different user populations must keep them documented separately.
Trust & references
Cross-checked against the following references.
- Auth Providers referenceSalesforce
- Single Sign-On overviewSalesforce
Straight from the source - Salesforce's reference material on Auth. Providers.
- Auth ProvidersSalesforce Help
- Configure an OpenID Connect Auth ProviderSalesforce Help
- Auth Namespace (Registration Handler reference)Salesforce Developers
Hands-on resources to go deeper on Auth. Providers.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What are Auth. Providers used for?
Q2. What is the registration handler?
Q3. Which of these is NOT a built-in supported provider?
Discussion
Loading discussion…