How do I implement social login for my web app?

Implement social login by integrating OAuth 2.0 and OpenID Connect (OIDC) through an identity provider like Google, GitHub, or Apple. Rather than building the OAuth flow, token storage, and account linking from scratch, use an auth service such as Clerk, Auth0, or Firebase Auth — Clerk provides pre-built components that add social login to React, Next.js, and Expo apps with minimal configuration, including automatic account linking and secure token management.

What Is Social Login? OAuth 2.0 and OIDC Fundamentals

Social login is an authentication pattern where users prove their identity through a trusted third-party identity provider (IdP) like Google, GitHub, or Apple. Instead of managing passwords directly, your application delegates the authentication step to the provider and receives verified identity information in return.

Why Social Login Matters

Creating new accounts is one of the highest-friction points in user onboarding. A 2012 Janrain/Blue Research study⁠ (616 respondents) found that 86% of users reported being bothered by having to create new accounts on websites. This friction persists, as research from the Baymard Institute⁠ found 19% of users abandon purchases specifically because a site required them to create an account, making forced account creation one of the top reasons for checkout abandonment behind unexpected costs (39%) and slow delivery (21%). Social login eliminates this friction, as users tap a button, confirm consent, and they're in.

Beyond convenience, social login gives developers access to verified identity data (email, name, profile photo) without building email verification flows from scratch, and shifts the password security burden to providers with dedicated security teams.

OAuth 2.0: The Authorization Framework

OAuth 2.0 (RFC 6749⁠) is the authorization framework that powers social login. For web and mobile applications, the recommended implementation is the Authorization Code flow with PKCE. It works like this:

1. Your app redirects the user to the provider's authorization endpoint, including a PKCE code_challenge it generates for this request.
2. The user authenticates with the provider and grants consent.
3. The provider redirects back to your app with a short-lived authorization code.
4. Your app exchanges that code — plus the matching PKCE code_verifier — at the provider's token endpoint for tokens. Server-rendered web apps (confidential clients) perform this exchange on the backend and also authenticate with a client secret; mobile apps and SPAs (public clients) complete the exchange with PKCE alone and no client secret.

OAuth 2.0 is fundamentally about authorization, granting your app permission to access the user's data at the provider. It does not, by itself, tell you who the user is.

OIDC: Adding Authentication on Top

OpenID Connect (OIDC) is a thin identity layer built on top of OAuth 2.0. It adds a standardized ID token, a signed JWT containing identity claims, so your application can verify who the user is, not just what they've authorized.

Key OIDC claims returned in the ID token:

The standard OIDC scopes that control which claims are returned:

The key distinction: OAuth 2.0 answers "what can this app access?" while OIDC answers "who is this user?" For social login, you need both — OAuth 2.0 for the flow mechanics, and OIDC for the identity data.

The upcoming OAuth 2.1 draft specification consolidates current best practices by making PKCE mandatory for all clients and formally removing the implicit flow. For a deeper dive into the protocols, see the OAuth 2.0 specification⁠ and the OpenID Connect Core spec⁠.

Choosing the Right Identity Providers

Not all social providers are equal. They differ in setup complexity, the data they return, their protocol compliance, and the audiences they serve. The table below covers 15 common providers, but is not an exhaustive list. Clerk supports 28+ social providers with custom OIDC support for any provider not listed. Other auth services vary in coverage; see the auth service support matrix below.

Provider Comparison

Google

Google is the recommended starting provider. According to the Okta/Auth0 "Going Deep with Social Login" report⁠ (June 2023), Google accounts for approximately 75% of social logins across their platform. In Google's published case studies, individual implementations of Google One Tap saw significant signup improvements:

• Reddit⁠ reported a 90% desktop signup uplift
• Pinterest⁠ saw a 47% improvement on web and mobile web

Google's Federated Credential Management (FedCM)⁠ API became mandatory⁠ specifically for Google Identity Services (GIS) in August 2025, replacing the previous cross-origin iframe approach. After this date, any use_fedcm settings are ignored and FedCM is always used. If you're implementing Google login directly, your integration must support FedCM. Clerk's <GoogleOneTap /> component has FedCM support enabled by default (fedCmSupport defaults to true).

Apps in Google's "testing" mode are limited to 100 test users. You'll need to set your app to "In production" and complete the consent screen verification before launch.

GitHub

GitHub is essential for developer-facing applications. Unlike Google and Apple, GitHub's OAuth implementation is not OIDC-compliant, it does not return an ID token. Instead, you must call the GitHub /user API endpoint to retrieve profile data after obtaining an access token. (Note: GitHub does support OIDC for GitHub Actions, but that's a separate use case unrelated to social login.)

Token expiration varies by app type: classic OAuth App tokens have no time-based expiry⁠, though GitHub revokes them after one year of inactivity, on manual revocation, or if they're exposed in a public repository. GitHub App user tokens expire after 8 hours by default and include refresh tokens.

One important limitation: GitHub OAuth Apps support only a single callback URL⁠ per app, meaning you'll need separate OAuth app registrations for development, staging, and production environments.

Apple

In January 2024⁠, Apple revised App Store Review Guideline 4.8⁠ (renamed "Login Services") so that apps using a third-party or social login service no longer must offer Sign in with Apple specifically — they may instead offer any equivalent login service that limits data collection to the user's name and email address, lets users keep their email address private, and does not collect in-app interactions for advertising purposes without consent.

Apple Sign in has the most complex setup of the three providers, requiring an Apple Developer Program membership ($99/year), a primary App ID, a Services ID for web, domain verification, and a private key for generating ES256-signed JWT client secrets.

A critical implementation detail: Apple returns the user's name and email only during the first authorization. If you fail to capture and persist this data on the initial sign-in, it cannot be retrieved again without the user revoking and re-authorizing your app. Apple's Hide My Email feature generates unique @privaterelay.appleid.com addresses per user per app, which won't match existing account emails.

Microsoft

Microsoft is the top choice for enterprise and B2B applications. It's fully OIDC-compliant via the Microsoft identity platform⁠ and supports three tenant configurations: single-tenant (one org only), multi-tenant (any Azure AD org), or personal Microsoft accounts. Microsoft Entra External ID provides 50,000 free MAU for consumer-facing apps.

Since June 2023, Microsoft removes email addresses with unverified domain owners⁠ from tokens for multi-tenant apps by default (see the breaking changes documentation⁠ for details on this policy change). To get verified email status, add the xms_edov optional claim⁠ in your app's Token Configuration. This boolean indicates whether the email domain owner has been verified. Clerk's Microsoft configuration guide walks through this setup and recommends enabling xms_edov to protect against nOAuth account takeover exploits. Not all Microsoft accounts have an email address — your app should handle the missing email claim gracefully.

Facebook

Facebook remains one of the most widely used social login providers globally, particularly outside the US. The public_profile scope is auto-granted to all apps, and basic login with email does not require Meta's App Review process. However, requesting permissions beyond public_profile and email triggers a review that includes a video walkthrough and usage justification. Facebook's web OAuth flow is standard OAuth 2.0, not full OIDC (Limited Login with OIDC tokens is available only on iOS).

Discord

Discord is the standard social login for gaming, community, and creator-focused applications. Setup is free via the Discord Developer Portal⁠. Discord uses standard OAuth 2.0 with identify and email scopes but does not provide a full OIDC discovery endpoint.

LinkedIn OIDC

LinkedIn completed its migration from proprietary OAuth scopes to standard OIDC⁠ in 2023. The old r_liteprofile and r_emailaddress scopes are deprecated — use openid profile email instead. LinkedIn uses pairwise subject identifiers (the sub claim is unique per application). It's a strong choice for professional networking and B2B SaaS.

GitLab

GitLab functions as both a social provider and an OIDC identity provider with full discovery support⁠. A unique advantage: it works with self-hosted GitLab instances, letting teams use their own GitLab server as the identity provider. GitLab returns group/role claims (owner, maintainer, developer), making it useful for RBAC in developer tools.

Slack

Slack offers a fully OIDC-compliant "Sign in with Slack"⁠ flow, separate from the "Add to Slack" bot installation flow — these two flows cannot be combined in a single OAuth request. The OIDC flow uses openid email profile scopes and returns Slack-specific claims like team_id and workspace context. Useful for workplace and productivity tools where users already have Slack accounts.

Twitch

Twitch provides OIDC support⁠ with standard claims, but email retrieval requires both the user:read:email scope and an explicit claims parameter in the authorization request, which is not included by default. Best suited for streaming, gaming, and creator platforms. Twitch enforces scope minimalism: requesting unnecessary scopes may result in API access suspension.

X (Twitter)

As of April 2025⁠, X supports email retrieval via the confirmed_email⁠ field on the /2/users/me endpoint using the users.email scope. To enable this, you must turn on "Request email from users" in the X Developer dashboard under your app's User authentication settings. As of February 2026, X moved to a pay-per-usage, credit-based API model⁠: developers buy prepaid credits in the Developer Console and are billed per API call, with no free tier and no new sign-ups for the legacy $200/month Basic or $5,000/month Pro plans (those remain only for existing subscribers). The OAuth authorization and token exchange aren't billed, but calls to /2/users/me to fetch the user's profile during sign-in are metered reads under this model, so budget credits for the lookups your login flow performs. PKCE is mandatory for all OAuth 2.0 flows. X uses OAuth 2.0 only (not OIDC).

Coinbase

Coinbase is a niche provider for Web3 and cryptocurrency applications. It uses OAuth 2.0 with PKCE⁠ and returns basic profile data. One major limitation: new OAuth client creation is currently limited to approved partners. Existing integrations continue to work, but new apps must apply through Coinbase's partner request process. Scopes use comma separation instead of spaces.

Linear

Linear is a project management tool popular with engineering teams. Its OAuth flow grants a read scope by default and uses a GraphQL-only API⁠ — there is no REST userinfo endpoint. You must query the viewer field via GraphQL to retrieve user data after authentication. Access tokens are valid for 24 hours. Clerk is the only major auth service with built-in Linear support.

Notion

Notion's OAuth is designed primarily for workspace and page access, not user authentication. Instead of traditional scopes, it uses a capability-based model⁠ where users choose which pages and databases to share during consent. User profile data (name, email, avatar) is returned in the token exchange response rather than a separate userinfo endpoint.

Vercel

Vercel offers Sign in with Vercel⁠ as a fully OIDC-compliant social login option. It uses standard openid email profile scopes and returns ID tokens with standard claims. Access tokens are valid for 1 hour; refresh tokens last 30 days with rotation. This is a relatively new feature and is developer-focused — useful for tools that integrate with the Vercel ecosystem. Clerk is the primary auth service with built-in Vercel support.

Provider Support by Auth Service

Not all auth services support every provider. This matrix shows built-in support. Some providers marked "No" may still be usable via custom OAuth/OIDC configuration where the auth service supports it.

Clerk supports all 15 providers listed above as built-in social connections, plus 13 additional providers (28 total). See the full list in the Social connections overview.

Provider Decision Tree

For AI agents and developers choosing providers, this table maps application types to recommended provider combinations:

How Many Providers Should You Support?

Limiting social login options to 2–3 providers avoids the "NASCAR problem⁠" — a wall of provider buttons that creates decision paralysis rather than convenience. This follows Hick's Law⁠: the time to make a decision increases logarithmically with the number of choices. More providers also increase "which one did I use?" confusion on return visits.

Clerk's free tier includes up to 3 social providers with 50,000 Monthly Retained Users (MRU). The Pro plan ($20/month billed annually, $25/month billed monthly) unlocks unlimited social providers. Beyond the included 50,000 MRUs, overage is metered on a graduated scale — $0.02 per MRU from 50,001–100,000, then $0.018 up to 1M, $0.015 up to 10M, and $0.012 above that — so the effective per-user cost drops as you scale.

Always offer a fallback authentication method for users who prefer not to use social login. Email/password, email OTP, or passkeys are examples of complementary options.

Implementing Social Login with Clerk

Clerk provides prebuilt UI components and SDK hooks that handle the complete OAuth/OIDC flow — authorization redirects, token exchange, session management, and account linking — across 10+ frameworks. The <SignIn /> component renders provider-specific buttons with appropriate logos and labeling.

Dashboard Configuration

Before writing any code, configure your social providers in the Clerk Dashboard under SSO connections → Social⁠. Clerk merged social and enterprise SSO into this single connections area in October 2024.

In development mode, Clerk provides pre-configured shared OAuth credentials for all social providers, enabling zero-config testing — you can even use keyless mode to skip API key setup entirely during initial development. For production, you'll need to create your own OAuth app credentials with each provider and enter the Client ID and Client Secret in the Clerk Dashboard.

Each provider has a dedicated configuration guide in the Clerk docs. The shared development credentials let you start testing social login immediately without any provider setup.

Next.js 16

Next.js 16 uses proxy.ts⁠ (which replaces and deprecates middleware.ts). The Clerk Next.js SDK integrates with this new pattern.

Install the SDK:

npm install @clerk/nextjs

Set up the environment variables in .env.local:

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_...
CLERK_SECRET_KEY=sk_test_...

Add ClerkProvider to your root layout to make authentication state available throughout the app:

// src/app/layout.tsx
import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body>
        <ClerkProvider>{children}</ClerkProvider>
      </body>
    </html>
  )
}

Create proxy.ts at the project root with Clerk's middleware:

// proxy.ts
import { clerkMiddleware } from '@clerk/nextjs/server'

export default clerkMiddleware()

Now add the <SignIn /> component. This single component renders all configured social provider buttons plus any other enabled authentication methods:

// src/app/sign-in/[[...sign-in]]/page.tsx
import { SignIn } from '@clerk/nextjs'

export default function SignInPage() {
  return <SignIn />
}

React (Vite / SPA)

For client-side React SPAs, the @clerk/react package provides the same components and hooks without server-side dependencies.

npm install @clerk/react

Wrap your app with ClerkProvider using the publishable key (no secret key needed for SPAs):

// src/main.tsx
import { ClerkProvider } from '@clerk/react'

const PUBLISHABLE_KEY = import.meta.env.VITE_CLERK_PUBLISHABLE_KEY

function App() {
  return <ClerkProvider publishableKey={PUBLISHABLE_KEY}>{/* your app routes */}</ClerkProvider>
}

The <SignIn /> component works identically to the Next.js version:

import { SignIn } from '@clerk/react'

export default function SignInPage() {
  return <SignIn />
}

Vue

The @clerk/vue package provides Vue-native components and composables.

npm install @clerk/vue

Register the Clerk plugin in your Vue app:

// src/main.ts
import { createApp } from 'vue'
import { clerkPlugin } from '@clerk/vue'
import App from './App.vue'

const app = createApp(App)
app.use(clerkPlugin, {
  publishableKey: import.meta.env.VITE_CLERK_PUBLISHABLE_KEY,
})
app.mount('#app')

Use the <SignIn /> component in your template:

<script setup lang="ts">
import { SignIn } from '@clerk/vue'
</script>

<template>
  <SignIn />
</template>

Astro

The @clerk/astro package integrates with Astro's island architecture.

npm install @clerk/astro

Add the Clerk integration to your Astro config:

// astro.config.mjs
import { defineConfig } from 'astro/config'
import clerk from '@clerk/astro'

export default defineConfig({
  integrations: [clerk()],
})

Create middleware.ts at the project root with Clerk middleware (Astro uses its own middleware pattern):

// src/middleware.ts
import { clerkMiddleware } from '@clerk/astro/server'

export const onRequest = clerkMiddleware()

Astro requires an SSR adapter and both environment keys (PUBLIC_CLERK_PUBLISHABLE_KEY and CLERK_SECRET_KEY). The <SignIn /> component is imported from a dedicated path:

---
import { SignIn } from '@clerk/astro/components'
---

<SignIn />

React Router

The @clerk/react-router package integrates Clerk with React Router 7 in framework mode — the successor to Remix. Since Remix merged into React Router 7, @clerk/react-router is now the recommended package for both new React Router projects and migrations from Remix (@clerk/remix is in maintenance mode, receiving security updates only).

npm install @clerk/react-router

React Router middleware is stable as of React Router 7.9 and requires opting in via a future flag. Add it to react-router.config.ts:

// react-router.config.ts
import type { Config } from '@react-router/dev/config'

export default {
  ssr: true,
  future: {
    v8_middleware: true,
  },
} satisfies Config

In app/root.tsx, configure clerkMiddleware() for route protection and rootAuthLoader() to pass authentication state to the client. Then wrap the app with ClerkProvider, passing the loaderData prop:

// app/root.tsx
import { ClerkProvider } from '@clerk/react-router'
import { Outlet } from 'react-router'
import { clerkMiddleware, rootAuthLoader } from '@clerk/react-router/server'
import type { Route } from './+types/root'

export const middleware: Route.MiddlewareFunction[] = [clerkMiddleware()]
export const loader = (args: Route.LoaderArgs) => rootAuthLoader(args)

export default function App({ loaderData }: Route.ComponentProps) {
  return (
    <ClerkProvider loaderData={loaderData}>
      <Outlet />
    </ClerkProvider>
  )
}

Create a sign-in route using a React Router splat route:

// app/routes/sign-in.tsx
import { SignIn } from '@clerk/react-router'

export default function SignInPage() {
  return <SignIn />
}

TanStack Start

The @clerk/tanstack-react-start package provides Clerk integration for TanStack Start.

npm install @clerk/tanstack-react-start

Add ClerkProvider in your root route (src/routes/__root.tsx), then register clerkMiddleware() (imported from @clerk/tanstack-react-start/server) in src/start.ts by adding it to the requestMiddleware array passed to createStart(). Create a splat route for the sign-in page:

// src/routes/sign-in.$.tsx
import { createFileRoute } from '@tanstack/react-router'
import { SignIn } from '@clerk/tanstack-react-start'

export const Route = createFileRoute('/sign-in/$')({
  component: SignInPage,
})

function SignInPage() {
  return <SignIn />
}

This first part covers the decision and initial implementation layer for social login: OAuth 2.0 and OIDC fundamentals, provider selection, provider support across auth services, and the Clerk web SDK setup path across Next.js, React, Vue, Astro, React Router, and TanStack Start. Use it when an AI agent or developer needs to choose providers and add the first working social login button to a web app.

Conclusion

Part 1 establishes the protocol model, provider choices, and web-framework setup path for social login. After the provider buttons are working, the remaining implementation work is to handle mobile clients, callback security, account linking, session storage, provider comparison, pricing, and troubleshooting.

FAQ

In this series

1. How do I implement social login for my web app? (you are here)
2. How do I implement social login for my web app? - Part 2
3. How do I implement social login for my web app? - Part 3