You click "Sign in with Google." The page jumps away, jumps back a second later, and you are in. So why the round trip — why not just type something on this page?
Because the safe way is to never hand over your password.
The old way: hand over your password
Twenty years ago, if a site wanted to read your data somewhere else, you gave it your password. Convenient — and costly:
- It stored your password, sometimes in plaintext.
- It got the full set, so it could do things you never agreed to.
- To undo it, you could only change your password — which logged you out everywhere else too.
The new way: bounce out, approve, bounce back
The password stays put. You click "Sign in with Google": you bounce to Google, sign in, and approve; you come back with a single-use ticket — the authorization code; the site trades that ticket for an access token — a pass that says on whose behalf, until when, and what it can do. The site never touches your password.
What you get back: a pass with a scope
The pass carries three things: on whose behalf, until when, and what it can do. Whatever you did not tick is not on the pass, and the door stays shut (scope, RFC 6749 3.3). The pass expires, and you can revoke it anytime under "authorized apps."
How it got here: 1.0 to 2.0 to patches
| Stage | When | What changed |
|---|---|---|
| OAuth 1.0 | 2007 (RFC 5849) | First version; convoluted, everyone rolled their own |
| OAuth 2.0 | 2012 (RFC 6749) | Rewritten into one common version; codes become single-use |
| PKCE | 2015 (RFC 7636) | A proof key makes a stolen code useless |
| Security BCP | 2025 (RFC 9700) | Implicit flow deprecated; PKCE mandatory |
The real opening: the consent step
The danger is not the password — it is you, at the consent prompt. In 2022, attackers built malicious OAuth apps (one even passed a Verified Publisher review) that tricked people into clicking approve — then quietly read their email and calendar (Microsoft / Proofpoint). That "bounce out" is your one clear look: see who is asking before you approve.
Three things people get wrong
- "Sign in with X" is not the same as the site being secure. Your password only went to the provider.
- It is not a login protocol. OAuth is authorization; proving who you are is OIDC.
- Approving is not forever. You can revoke access under "authorized apps."
Takeaway
With third-party sign-in, the site never gets your password. It gets a scoped, expiring, revocable pass.
These practices come from building Autional, an open-core identity and access management platform — https://www.autional.com
Reference: RFC 6749, RFC 7636, RFC 9700, RFC 5849, OpenID Connect Core 1.0; case: Microsoft consent phishing (2022).
Top comments (0)