What is OAuth — and why 'Sign in with Google' never gives away your password

You hit "Sign in with Google" on a new site. Two clicks later you're in. And here's what most people don't notice: the site never learned your Google password. Not at all. Not a single letter.

It sounds like a trick, but that's exactly the point of OAuth — a standard by which one service lets you into another without handing over your password. You meet it every day: "Sign in with Google," "Continue with Apple," connecting Telegram to a bot. Let's see how it works — and why it's safer than it looks.

The hotel analogy

Imagine checking into a hotel. The front desk doesn't give you the master key to the whole building. It gives you a keycard to your room — it opens only that room, works until checkout, and can be deactivated at any time.

OAuth is exactly that front desk, just digital:

• You — the guest.
• Google — the front desk that knows you (it has your password).
• The new site — the door you want to enter.
• The access token — that keycard: limited, temporary, revocable.

The site gets not your password but a keycard. And that card says precisely: "this person is who they claim to be, and allowed you to see their name and email." No more.

What happens, step by step

When you hit the button, this runs in half a second:

1. The site sends you to a Google page — the real one, on google.com. You type your password only here, if you're not already logged in.
2. Google asks: "Site X wants your name and email. Allow?" You see exactly what you're giving up.
3. You hit "Allow" — Google issues the site a token (that keycard).
4. The site uses the token to call Google's API: "who is this?" — gets the name and email, and lets you in.

The key thing: you entered your password on Google's side, not on some third-party site. So even if that site is hacked tomorrow, your password isn't there — nothing to steal.

Why this matters to you as an app builder

Two reasons, both strong.

For the user — zero friction. No new password to invent, no email to confirm. One tap and they're in. That noticeably lifts how many people actually sign up.

For you — you don't store passwords. And passwords are a headache and a risk: they must be hashed, protected, recovered. With OAuth, Google or Apple handles that, and you just receive a verified name and email. Less code, fewer ways to mess up security.

Under the hood, after login the site usually issues you its own session token, which the browser stores and sends with each request. The keys and secrets for OAuth, meanwhile, live not in code but in environment variables. But that's the next layer; the keycard picture is enough to understand OAuth.

FAQ

Are OAuth and a password the same thing?

No. A password is a secret you type. OAuth is a way to log in without handing the password to a third-party site: you confirm your identity with a trusted service (Google, Apple), and the site only gets a temporary token.

Is it safe to grant access via Google?

Yes, and usually safer than creating a new password. You always see exactly what you're giving up (name, email), and you can revoke access in your Google settings any time — like deactivating a keycard. The one rule: only type your password on Google's/Apple's own page, checking the domain.

What if I want to add this login to my own app?

You don't need to implement OAuth from scratch — it's hard and easy to do insecurely. Ready services (Supabase, Clerk, Auth0) give you a "Sign in with Google" button in a couple of lines. How to do it step by step is in the guide how to add login to your app.