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.

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)
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
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
Quick check
Which value should you store to recognise a returning Google user?
Go deeper
- 1Implement 'Sign in with Google' end-to-end using OAuth or a library like Passport.
- 2Handle the case where a social login email matches an existing local account.
- 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.