Stop 10 · Authentication & AuthorizationTopics · 8/11

Social Login (Google/GitHub)

Part of the Backend Developer Roadmap

In short

Every signup form loses a few people. 'Continue with Google' lets users sign in with an account they already trust, and you never have to store their password at all.

Letting users sign up or log in using an existing account on Google, GitHub or similar providers, reducing signup friction and password-management burden.

The blob character is let into a party because a friend inside vouches for it.

Think of it like this

A friend vouches for you

At a party, the doorkeeper doesn't know you. But a regular guest he trusts waves and says, 'She's with me.' You're in, no questions. Social login works the same: Google or GitHub vouches for who the user is, and your app trusts that.

Watch it happen

Continue with Google (OpenID Connect)

User
Your app
Google

Continue with Google

1/6The user clicks the button on your login page.

The big ideas

What you need to know

It's usually OpenID Connect

Google sign-in is OIDC on top of OAuth 2.0. You get an ID token that says who the user is.

Key on sub, not email

Store the provider's sub claim as the identity. Emails can change; sub stays the same for that account.

Link accounts carefully

If a Google email matches an existing user, merge only when the provider says the email is verified.

Then use your own session

After verifying, create your normal session or JWT. Don't keep forwarding Google's tokens to your API.

See it in code

Walk through the code

ts
1import { OAuth2Client } from "google-auth-library";2 3const google = new OAuth2Client(process.env.GOOGLE_CLIENT_ID);4 5export async function loginWithGoogle(idToken: string) {6  const ticket = await google.verifyIdToken({ idToken, audience: process.env.GOOGLE_CLIENT_ID });7  const p = ticket.getPayload();8  if (!p || !p.email_verified) throw new Error("Email not verified");9 10  const user =11    (await db.users.findByProvider("google", p.sub)) ??12    (await db.users.create({ provider: "google", providerId: p.sub, email: p.email, name: p.name }));13  return user;14}

1/3A client set up with your Google OAuth client id.

The ID token comes from the code exchange, or from Google's sign-in button on the frontend. After this, start your own session.

Save yourself the pain

Common mistakes

Oops

Trusting an ID token from the frontend without verifying it.

Do this instead

Anyone can craft fake JSON. Verify the signature and audience on the server, every single time.

Oops

Using email as the only link to the provider account.

Do this instead

Store provider and sub together. Emails can change or be reassigned; sub is stable.

Your mission

Add Continue with GitHub

~45 min

Quick check

Which value should you store to recognise a returning Google user?

Go deeper

  1. 1Implement 'Sign in with Google' end-to-end using OAuth or a library like Passport.
  2. 2Handle the case where a social login email matches an existing local account.
  3. 3Learn what profile data each provider actually returns after consent.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge