Letting users sign in through a provider they already trust, so you never handle their password.
Why it exists
Users hate creating yet another password, and a product should not have to store one if it can avoid it. Asking people to trust every small site with new credentials is friction and risk. OAuth exists so a user can prove their identity through a provider they already trust, like Google, and grant limited access without that site ever seeing their password.
How it actually works
Instead of creating yet another password, the user clicks "Login with Google." They authenticate with Google, and Google tells your app "yes, this is really them, here is their email." Your app trusts that and logs them in.
You never see or store their Google password. You are borrowing the identity check from a provider who does it well, which reduces both user friction and your security burden.
A senior PM walks you through it
A junior PM, stuck
I proposed Login with Google to cut our sign-up drop-off, and the tech lead asked whether I understand what Google actually sends TiffinBox when someone uses it. I said the email, then realized I was guessing. I do not know what leaves Google, or whether we somehow get their password.
Fair question, and the answer is exactly two real things you can read. When a user taps Login with Google, TiffinBox sends them to a Google URL that names what it is asking for, and Google later sends back a small block of user info. No password is ever in either one. I pulled both: the outgoing URL and the info that comes back. Read the labeled parts and you can answer your tech lead precisely.
The Google login URL TiffinBox opens, and what Google returns
Where TiffinBox sends the user
1:22
28471
3:
4
5372
6
What Google sends back to TiffinBox
7{
8"email":"customer@gmail.com",
9"email_verified":true,
10"name":"the customer",
11"sub":"google-uid-1137742"
12}
Click a step to see the lines it points at.
Mistakes I've seen
Telling stakeholders "Google shares the account" as if TiffinBox gets broad access. It gets exactly what scope lists, here just email and profile. Overstating it invites a privacy objection that is not real.
Assuming social login means TiffinBox stores the Google password. It never sees the password. The whole point is that Google does the identity check and hands back only the fields in the second block.
Forgetting the dependency cost. If Google login has an outage, those users cannot sign in at all. Offering email login alongside is the usual answer, and that is a product decision to make up front.
Reading email_verified as optional detail. It is the reason you can trust the address without your own confirmation email. If it were false, you would still need to verify it yourself.
Confusing the scope you request with account control. A wider scope is more to justify to the user and more to secure. Ask for the minimum the feature needs, which for login is email and profile.
Answer your tech lead with: "Google sends us a verified email and a stable user id, scoped to email and profile, and never a password. We check the state value to trust the callback." You read the actual URL and the actual response, so that is not a guess anymore. That is what OAuth hands you.
Where a PM meets this
Social login lifts sign-up conversion (no new password) but ties you to providers and gives you less control over the account. That trade is a product call.
Some users distrust connecting accounts; offering both social and email login is common for this reason.
Hear it in a meeting
"Adding Google login should cut sign-up drop-off, let's measure it."