How to Add Social Login (Google, GitHub, Apple) to Your SaaS

You added email auth. Conversion was fine. Then you A/B tested a “Continue with Google” button and conversion jumped 24% overnight. Now you have to explain to yourself why you waited.

Social login is one of the cheapest signup-conversion lifts available to indie SaaS in 2026. Industry data puts the average lift at 20-35% on signup pages. And yet, half of indie products still ship with email-only auth because the OAuth setup looks intimidating from the outside.

This post is the practical guide to adding Google, GitHub, and Apple social login to your SaaS without losing a weekend. The OAuth flow explained simply, the security mistakes that show up in 90% of DIY implementations, and the shortcuts that get you shipping in minutes instead of days.

Why Social Login Wins on Signup

Three things happen when you add social login to a signup page:

Friction drops to one click. No password to choose, no email to type, no captcha to solve. The user goes from “I want to try this” to “I am inside the app” in under five seconds.

Conversion lifts 20-35%. This is consistent across studies: SaaS, e-commerce, mobile, B2B, and B2C all see the lift. The exact number varies by audience — developer tools see closer to 35% (GitHub login is highly trusted), consumer apps see 20-25%.

Trust transfers from the provider. Users skeptical of a brand-new app trust it more if Google or Apple stands between them and signup. Your product borrows their security reputation.

The only category where social login does not lift is enterprise-only B2B with mandatory SSO — and even there, “Continue with Google Workspace” beats email-and-password.

The OAuth 2.0 Flow Explained Simply

OAuth sounds intimidating because the spec is long. The actual flow is five steps:

1. User clicks “Continue with Google” on your site.
2. Your site redirects them to Google with a URL containing your client ID, the requested scopes, and a redirect URI.
3. User signs in to Google and approves the requested permissions.
4. Google redirects back to your site with a one-time code in the URL.
5. Your server exchanges the code for an access token + ID token by calling Google’s token endpoint with your client secret.

The ID token is what matters for auth — it is a signed JWT containing the user’s email, name, and Google ID. You verify the signature, extract the user info, and create or look up a user in your database.

The whole round trip takes about 2 seconds. Done correctly, the user just sees: click button, see Google consent, land back on your app logged in.

What You Need from Each Provider

The setup steps are similar for every OAuth provider but the dashboards are all different.

Google

1. Go to Google Cloud Console, create or select a project.
2. Enable the Google+ API (now called People API in some regions).
3. Configure the OAuth consent screen — pick “External” user type, fill in app name, support email, and authorized domain.
4. Create OAuth 2.0 Client ID credentials. Pick “Web application.” Add your authorized JavaScript origins (https://yourapp.com) and authorized redirect URIs (https://yourapp.com/auth/callback/google).
5. Save the Client ID and Client Secret — these are your environment variables.

The OAuth consent screen approval matters: in dev mode you can have up to 100 test users. To go live with unlimited users, submit the consent screen for verification (usually 3-5 business days, can be 6 weeks for sensitive scopes).

GitHub

GitHub is the simplest setup of the three:

1. Go to Settings → Developer settings → OAuth Apps → New OAuth App.
2. Set Application name, Homepage URL, and Authorization callback URL (https://yourapp.com/auth/callback/github).
3. Click Register application.
4. Generate a client secret on the next page.

That is it. No verification process, no consent screen review.

Apple

Apple is the most painful of the three. Required if you have an iOS app (App Store rule), nice-to-have for everyone else.

1. Apple Developer account ($99/year).
2. Create a Services ID in the Apple Developer portal.
3. Configure Sign in with Apple capability for the Services ID.
4. Generate a private key for the Sign in with Apple key.
5. Configure return URLs.
6. Generate a client secret JWT (Apple does not give you a static secret — you sign your own using the private key, valid for 6 months max).

For most indie SaaS not shipping iOS apps, skip Apple. Add it later when an iOS launch forces it.

The Code: Same Pattern, Three Providers

The OAuth flow is the same regardless of provider. Pseudocode for the route handlers:

// /auth/login/[provider] — initiate the OAuth redirect
export async function GET(req: Request, { params }) {
  const { provider } = params;
  const config = providers[provider]; // google, github, apple
  
  const state = generateRandomString();
  await storeStateInCookie(state);
  
  const url = new URL(config.authorizationUrl);
  url.searchParams.set("client_id", config.clientId);
  url.searchParams.set("redirect_uri", `${BASE_URL}/auth/callback/${provider}`);
  url.searchParams.set("response_type", "code");
  url.searchParams.set("scope", config.scopes);
  url.searchParams.set("state", state);
  
  return Response.redirect(url.toString());
}

// /auth/callback/[provider] — handle the redirect back
export async function GET(req: Request, { params }) {
  const { provider } = params;
  const code = new URL(req.url).searchParams.get("code");
  const state = new URL(req.url).searchParams.get("state");
  
  await verifyStateMatchesCookie(state);
  
  const tokens = await exchangeCodeForTokens(provider, code);
  const userInfo = await verifyIdToken(provider, tokens.id_token);
  
  const user = await findOrCreateUser({
    provider,
    providerId: userInfo.sub,
    email: userInfo.email,
    name: userInfo.name
  });
  
  return createSessionAndRedirect(user, "/dashboard");
}

That same shape works for Google, GitHub, and Apple with different URLs and scopes. The hard parts are not the routing — they are the security details.

For deeper framework-specific tutorials, the Add Auth to a Next.js App guide covers the full setup including session management, and the same pattern adapts to Astro, Remix, or SvelteKit.

Security Mistakes Almost Every DIY Implementation Makes

Five mistakes that show up in 90% of self-built social login implementations. Avoid them.

1. Skipping the State Parameter

The state parameter is a random string you send to the OAuth provider and verify when they redirect back. Without it, you are vulnerable to CSRF — an attacker can craft a malicious OAuth callback URL and trick a logged-in user into linking the attacker’s account.

Always generate a random state, store it in a cookie tied to the user’s browser, and reject the callback if state does not match.

2. Trusting Frontend Tokens

If your frontend receives an ID token directly (e.g., Google’s One Tap), the backend still has to verify the JWT signature, check the aud claim matches your client ID, and confirm the iss claim matches Google’s issuer URL.

Skipping verification means anyone can craft a JWT claiming to be any user and trick your app into logging them in. This bug shows up in roughly 1 in 5 self-built OAuth integrations.

3. Storing the Access Token in localStorage

OAuth access tokens that end up in localStorage are accessible to any XSS vulnerability on your site. One stray third-party script and the attacker pulls every user’s token.

Use httpOnly, Secure, SameSite=Lax cookies for session tokens. Never expose OAuth access tokens to JavaScript unless you genuinely need to call the provider’s API from the browser.

4. Not Handling Email Conflicts

User signs up with email + password as [email protected]. Six months later, the same person clicks “Continue with Google” using the same email. What happens?

If you create a duplicate account, you have two records for one human. If you blindly link them, you have a security hole — anyone who controls Google’s account can take over the email-and-password account.

The right pattern: detect the conflict, ask the user to log in with their existing method first, then link the social account explicitly. Skipping this step is the single most common social-login bug at scale.

5. Forgetting to Validate the Redirect URI

Some providers (older Google integrations especially) let you pass an arbitrary redirect_uri at request time. If your config does not strictly whitelist URIs, an attacker can craft a redirect to their own server and steal the auth code.

Always set explicit redirect URIs in the provider’s dashboard and reject any callback that does not match exactly.

The Indie Hacker Shortcut

You can do all of the above by hand. Or you can use a managed auth product that ships it correctly out of the box.

Beag.io handles Google, GitHub, Apple, and email/magic-link login as a single library. State CSRF, ID token verification, httpOnly session cookies, account linking on email conflicts — all wired up correctly with one install. Plug in your Stripe pricing and you have a real SaaS in an afternoon.

If you prefer to roll your own anyway, the libraries to consider in 2026:

• Auth.js / NextAuth v5 — the de facto standard for Next.js. Solid, well-maintained, supports every major provider.
• Better Auth — newer TypeScript-first auth library. Cleaner DX than NextAuth for greenfield projects.
• Lucia — minimal, framework-agnostic. Good if you want fine control without the abstraction.
• Clerk / WorkOS — managed services if you want to outsource the auth surface entirely.

The right choice depends on whether you want speed or control. For most indie hackers, “speed” wins — pick a managed product and go ship the actual product.

Which Providers to Support

Not every product needs every provider. The matrix that maps audience to providers:

• Developer tools — GitHub is non-negotiable. Google as backup. Skip Apple.
• Consumer apps — Google + Apple. Optional GitHub if your audience is technical.
• B2B SaaS — Google (covers Google Workspace) + Microsoft (covers Office 365). Skip Apple unless you have an iOS app.
• Indie / niche — Just Google to start. Add GitHub if your traffic is technical, Apple if you launch on iOS.

Adding too many providers fragments your user data (“Why is one user logged in via Google, another via GitHub, and a third via email?”). Pick two or three that match your audience and stop.

For comparing managed auth options, Auth0 vs Clerk vs Supabase Auth covers the major hosted players including their social login support.

What Happens After Login

The OAuth dance is the easy part. Three post-login concerns that most tutorials skip:

Account linking. As covered above, design your data model so a single user can have multiple authentication methods. Either a users table with a JSON auth_methods column, or a separate user_identities table joining to users. Both work; pick one and stick with it.

Profile data sync. Google sends name, email, picture. GitHub sends login, email, avatar_url. Apple sends… almost nothing on subsequent logins (they hide the email behind a relay address by default). Decide what profile data you trust from the provider versus what the user fills in.

Session management. OAuth gets the user logged in once. After that, your session strategy (signed cookies, JWTs, database sessions) determines how long they stay logged in and across which devices. This is independent of OAuth — design it separately.

FAQ

Do I need a separate library for each OAuth provider?

No. Auth.js (NextAuth), Better Auth, Lucia, and most managed auth products handle every major provider through a single configuration. You wire up Google and GitHub the same way, just different config blocks.

Do I need to verify users’ emails after social login?

Generally no — social login providers verify the email before passing it to you. Google, GitHub, Microsoft all confirm email ownership during signup. The exception is Apple’s private relay address, which is opaque to you and cannot be re-verified.

What scopes should I request for social login?

The minimum: openid email profile (Google), read:user user:email (GitHub), name email (Apple). Requesting more scopes triggers the consent screen and can scare off users. Request additional scopes only when you actually need them, and ideally as an incremental consent flow.

How do I handle a user who signed up with email and now wants to add Google login?

Build an account-linking flow in your settings page: user is already logged in, clicks “Connect Google,” runs through OAuth, your callback finds an existing logged-in session and links the new identity instead of creating a new user. This is one of the cleaner UX patterns and almost no DIY tutorials cover it.

Is social login enough on its own, or do I still need email/password?

For most products you can ship social login only. Always offer at least 2 social providers (e.g., Google + GitHub) so users without one provider can still sign up. Adding email/magic-link as a fallback improves coverage further.

What happens if Google’s API goes down?

Users cannot log in via Google for the duration of the outage. This is rare but real. Mitigations: offer at least 2 auth methods so users have a fallback; set sensible session lengths so existing logged-in users do not get logged out during the outage; show a helpful error message rather than a generic “Something went wrong.”

---

Social login is one of the highest-leverage features you can ship to a SaaS in 2026. The friction drop on signup pays for the implementation effort within a single week of traffic, and the security model — when implemented correctly — is stronger than email/password.

If you want all of this — Google, GitHub, Apple, magic link, session management, and Stripe billing — working in five minutes instead of a weekend, Beag.io handles it for you. One install, one API key, one less thing to debug.