Social Login: Best Providers and How to Add Them

The best social login providers are the ones your users already have open: Google for almost every consumer and business app, Apple for anything on iOS, GitHub or GitLab for developer tools, and Microsoft for apps sold to companies. Two or three buttons cover most audiences; more than four slows people down. This guide shows which providers fit which audience, the rules app stores add, and how to add OAuth login with Google step by step.

#Social login providers by audience

A good rule: one button for the provider most of your users have, one for the platform they are on (Apple on iOS), and e-mail as a fallback for everyone else.

#What each major provider gives you

Google. The broadest reach. Returns a verified e-mail address, name and profile picture with the basic scopes. Works on web, Android and iOS, including native sign-in libraries that hand your app an ID token.

Apple. Required on iOS in many cases (next section). Users can hide their real address behind a relay e-mail, so do not assume the address you get is the one they type elsewhere.

GitHub. The default for developer tools. You can request extra scopes (for example repository access) during sign-in, but ask only for what you use; broad scopes scare users away.

Microsoft (Azure / Entra ID). Covers work and school accounts, so it is the B2B default next to Google. Tenant-specific setups let you restrict sign-in to one company.

Facebook. Still common in consumer apps. Read Meta's app review and data rules before you depend on it.

Discord, Twitch, Slack, LinkedIn, Notion, Figma, Zoom, Spotify. Niche, but the natural choice where the audience already lives: Discord for a gaming community, Slack for a workplace tool.

Keycloak and WorkOS. Not social providers in the usual sense: they connect your app to a company's identity system. For enterprise customers who want their own IdP, also look at SAML single sign-on.

#The App Store rule you cannot ignore

Apple's App Review Guideline 4.8 says that an app using a third-party or social login (Google, Facebook, X, LinkedIn and others) to set up the user's primary account must also offer an equivalent login option that limits data collection to name and e-mail, lets users keep their e-mail private, and does not track them for ads without consent. Sign in with Apple meets that. There are exceptions, for example apps that only use your company's own accounts, education or enterprise apps that require an existing organization account, and clients for a specific third-party service. Read the current wording in the App Review Guidelines.

Guideline 5.1.1(v) adds another requirement: if your app supports account creation, it must also offer account deletion inside the app. Plan for that on day one, whichever providers you use.

#How OAuth login with Google works

Social login is OAuth 2.0 (with OpenID Connect on top for identity). The flow your users see takes a few seconds; behind it:

1. Your app sends the user to Google with your client ID, the scopes you want and a callback URL.
2. The user signs in to Google and approves.
3. Google redirects back to the callback URL with a short-lived code.
4. Your auth server exchanges the code (plus your client secret) for tokens and the user's profile.
5. Your auth server creates or finds the user and starts a session in your app.

Steps 3 and 4 need a server that holds the client secret. A hosted auth service does them for you; that is most of the value.

#Step by step: Google login on StitchDB

StitchDB Auth supports 19 OAuth providers: Google, GitHub, GitLab, Microsoft (Azure), Apple, Discord, Facebook, Bitbucket, Twitch, Twitter (X), Spotify, Slack, LinkedIn, Notion, Zoom, Figma, Kakao, Keycloak and WorkOS (OAuth docs). Every provider is set up the same way.

#1. Create the OAuth client at Google

In the Google Cloud console, create an OAuth client ID of type Web application. As the authorized redirect URI, enter your project's callback:

https://<project-ref>.p.stitchdb.com/auth/v1/callback

Copy the client ID and client secret.

#2. Turn the provider on

In Studio open Authentication › Sign-in methods, open Google, paste the client ID and secret and enable it. The secret is stored encrypted and never shown again.

#3. Allow your app's URLs

Under Authentication › URL configuration, add the URLs your app should come back to, for example https://app.example.com/** and http://localhost:3000/** for development. A mobile deep link like myapp://auth/callback works too (redirect URLs).

#4. Add the button

import { createClient } from 'stitchdb-js'

const stitchdb = createClient('https://<project-ref>.p.stitchdb.com', anonKey, {
  auth: { flowType: 'pkce' },
})

async function signInWithGoogle() {
  const { error } = await stitchdb.auth.signInWithOAuth({
    provider: 'google',
    options: { redirectTo: 'https://app.example.com/auth/callback' },
  })
  if (error) alert(error.message)
}

#5. Finish on the callback page

With PKCE the user comes back with a one-time code, not tokens in the URL:

const code = new URL(location.href).searchParams.get('code')
await stitchdb.auth.exchangeCodeForSession(code)

The user is now signed in. Their account is a row in auth.users, and the provider is stored in app_metadata, which you can read in SQL:

select auth.uid(), auth.jwt() -> 'app_metadata' ->> 'provider';

#Native apps: use the ID token

On iOS and Android, the native Google and Apple sign-in libraries give you an ID token without a browser redirect. Pass it straight to Auth:

await stitchdb.auth.signInWithIdToken({ provider: 'google', token: idToken })

For native libraries that do not support nonces, Google and Apple have a Skip nonce check option in the provider settings. In Swift, signInWithOAuth(provider:redirectTo:) opens an ASWebAuthenticationSession and returns signed in:

try await stitchdb.auth.signInWithOAuth(provider: .github, redirectTo: URL(string: "myapp://login-callback"))

#One person, several buttons

A user signs up with e-mail in March and clicks "Continue with Google" in June. If the Google account has the same verified e-mail address, StitchDB links both to one user automatically. To let a signed-in user connect a provider with a different address, turn on Allow manual identity linking and call:

await stitchdb.auth.linkIdentity({ provider: 'github' })
const { data: { identities } } = await stitchdb.auth.getUserIdentities()

Users keep at least one identity, so they cannot unlink themselves out of their account (identity linking).

#Mistakes to avoid

• Too many buttons. Six logos make people stop and think. Pick two or three.
• Trusting user_metadata for roles. Names and avatars from the provider land in user metadata, which users can change. Put roles in app_metadata or your own tables.
• Forgetting the redirect allowlist. A redirectTo that is not on the list falls back to the Site URL, which defaults to http://localhost:3000.
• Broad scopes at sign-up. Ask for extra permissions later, when the user needs the feature.
• No e-mail fallback. Some users do not want to connect any social account.

If you would rather not build any of this UI, the hosted sign-in page shows every provider you turned on, next to e-mail and password.

#FAQ

#What is the best social login provider?

Google, for reach. On iOS add Apple, for developer tools add GitHub, and for B2B add Microsoft.

#Is Sign in with Apple required?

Often, for iOS apps that offer other social logins for the primary account. Apple's guideline 4.8 lists the exceptions; check it before you submit.

#Does social login cost money?

Check each provider's developer terms; the cost most teams notice is their auth service's per-user pricing. On StitchDB they count toward the plan's monthly active users (50,000 on Free). See pricing.

#Can I add social login to an existing e-mail and password app?

Yes. Enable the provider and add the button. Users with the same verified e-mail are linked to their existing account.

#How do I test OAuth locally?

Add http://localhost:3000/** to your redirect URLs and pass redirectTo: 'http://localhost:3000/auth/callback'. The provider's callback stays the StitchDB URL.

Related reading: React authentication. Add Google login today: create a free StitchDB project.