OAuth explained simply: how "sign in with Google" works

When you click "Sign in with Google", the application does not receive your password. It receives a limited permission, issued by Google with your consent. That is the idea behind OAuth.

The analogy: the front-desk pass

Picture an office building. For a courier to go up to the 4th floor, you would not hand over the key to the whole building. You go to the front desk, which gives the courier a pass: valid for one floor, for the day, and revocable.

OAuth is that front desk. The courier is the application; the desk is the service that knows your account (Google, Microsoft, GitHub...); the pass is a token.

How it unfolds, in four steps

1. The application redirects you to the trusted service.
2. You log in there, on its own site, and it asks what you agree to share (your name, your email address, your calendar...). These rights are called scopes.
3. The service sends you back to the application with a one-time code.
4. The application exchanges that code, on the server side, for a token that only allows what you accepted.

At no point does your password pass through the application.

A useful precision

OAuth originally handles authorization ("may this application do this?"). To answer "who is this person?", a standard layer called OpenID Connect is usually added. The sign-in button relies on both.

Good habits

• Ask for the minimum scopes. Each extra permission is an extra risk.
• Register the allowed return addresses precisely with the service, no wildcards.
• Keep the application's secret on the server, never in code sent to the browser; see exposed API keys.
• Use your technology's proven library rather than writing the exchange yourself: there are many fragile details.

For users

Check the list of permissions before accepting, and from time to time remove access for applications you no longer use, from your account settings.

Why not just ask for the password?

Because an application that holds your password holds everything, forever, and you cannot limit what it does. With a token, the service stays in control: it can narrow the rights, set an expiry, and cancel the access without changing your password.

Key takeaway

OAuth hands out a limited, revocable pass, never your password. For a product, it is often safer than managing passwords yourself, provided it is configured well.

And for your product?

A "sign in with Google" that is poorly configured (return addresses too broad, needless scopes, an exposed secret) still looks like it works. A code audit of your application reviews these points. If you want to discuss it, let us take 30 minutes.

Also worth reading: session or JWT, password hashing and this article on APIs.