The Button Everyone Clicks and Nobody Reads
"Sign in with Google." "Continue with Apple." One click, no new password, done. Behind that button run two related technologies: OAuth (the authorization protocol) and single sign on (the pattern of one identity unlocking many services). They are genuinely good engineering, and also worth understanding in detail before you wire fifty apps to one account.
Authentication vs Authorization: The Distinction That Explains Everything Else
These two words get used almost interchangeably in casual conversation, but the protocols treat them as completely different problems, and the difference is the key to understanding OAuth.
- Authentication answers "who are you." Proving you are the owner of an account, typically through a password, a passkey, or a code.
- Authorization answers "what are you allowed to do." Deciding whether a logged in identity can read a file, post to a feed, or view an email inbox.
OAuth, strictly, is an authorization protocol: it was designed to let one app get limited permission to act on your behalf inside another service, without ever handling that service's login step. Because so many apps wanted to also use the process to figure out who you are, an extra layer called OpenID Connect (OIDC) was built on top of OAuth specifically to add authentication back in, through something called an ID token. When you click "Sign in with Google," you are usually using OAuth plus OIDC together: OIDC tells the app who you are, and OAuth tells it what it is allowed to touch.
Step by Step: What Happens When You Click the Button
- Redirect to the provider. The app sends your browser to Google's (or Apple's, Facebook's, GitHub's) real login domain, not a page the app itself controls. This is the step that makes OAuth resistant to the app ever seeing your password: you are typing it, if at all, only on Google's own site.
- You authenticate with the provider. Password, passkey, or whatever method that account already uses, entirely inside Google's domain.
- The consent screen appears. "This app wants to: view your email address, see your basic profile." This list is the actual permission grant, called a scope list, and it is the only place you get to inspect what you are handing over before it happens.
- You approve, and the provider issues an authorization code. A short lived, single use code, valid for around a minute, sent back to the app through your browser's redirect.
- The app exchanges the code for a token, server to server. Away from your browser entirely, the app's backend sends the authorization code plus its own secret credential to Google's token endpoint, and receives back an access token (and often an ID token, under OIDC).
- The app uses the token. Every subsequent request to Google's API on your behalf includes the access token, which Google checks against the scopes you approved, nothing more.
The two step handoff (code first, then token exchange server side) exists specifically so that a stolen authorization code, intercepted somewhere in the browser redirect, is useless on its own: it needs the app's own secret to redeem it, and it expires within moments regardless.
Why the Token Model Beats Password Sharing
The problem OAuth solved: apps used to ask for your actual Google password to "import your contacts," which meant handing a stranger's app the keys to your entire account, forever, with no way to limit what it could do or take the access back without changing your password everywhere else too. OAuth's tokens fix all three problems at once:
- Scoped: a token is only good for the specific permissions listed on the consent screen, never your whole account.
- Revocable: you can kill one app's access without touching your password or any other connected app.
- Expiring: access tokens typically die on their own after an hour or so; a separate refresh token, used only server to server, quietly renews access without you noticing, but can itself be revoked at any time.
What SSO Adds on Top
Single sign on is the experience built from repeated OAuth/OIDC handoffs: one identity provider (your Google, Apple, Microsoft, or your company's Okta) vouches for you everywhere. Log in once each morning; every connected service trusts the introduction rather than asking again. Companies adopt it because offboarding an employee means disabling one central account, not two hundred individual ones scattered across every tool the company uses. Users adopt it because it collapses fifty passwords and fifty separate 2FA setups down to one of each.
The Trade-Off Nobody Mentions at the Consent Screen
SSO concentrates risk by design. All those eggs share one basket:
- The provider account becomes everything. Compromise your Google account, and every "Sign in with Google" service falls with it, in one motion, because the attacker can simply repeat the same login flow you use every day. Your identity provider account needs your absolute best protection: strongest password, app based 2FA at an absolute minimum, ideally a passkey or hardware key. Our Google 2FA guide and hardware key guide are the relevant homework before relying on SSO broadly.
- Lockout cascades. Lose access to the provider itself (a suspension, a forgotten recovery method, a deceased relative's account scenario), and every dependent service strands with it, all at once, rather than one account at a time.
- Consent phishing is a distinct, real attack. Attackers register innocent looking third party apps and phish you into approving OAuth scopes like mailbox reading or file access, entirely through a legitimate-looking consent screen on the real provider's domain. No password is stolen anywhere in this attack; the token itself is the theft, and it sails past every password based defense you have. Read consent screens like contracts, because functionally they are exactly that.
The consent screen is the entire security model. "View your email address" is harmless. "Read, send, and delete your email" requested by a PDF converter app is an alarm bell with a progress bar.
Audit Your Connected Apps (Ten Minutes, Twice a Year)
Years of one click logins leave a long tail of forgotten grants, many for apps you stopped using years ago but never revoked. Clean them on a schedule:
- Google: myaccount.google.com → Security → Third-party apps with account access. Revoke anything unused or over-scoped for what it actually needs to do.
- Microsoft: account.microsoft.com → Privacy → Apps and services.
- Facebook: Settings → Apps and websites.
- GitHub: Settings → Applications → Authorized OAuth apps, worth checking especially closely since developer accounts often grant broad repository access.
- Apple: Settings → Apple ID → Sign-In & Security → Sign in with Apple.
Every stale grant is standing permission held by a company, or a long abandoned side project, whose security you no longer think about at all, sitting quietly with live access to your account regardless.
SSO Login vs Direct Email Login: Which Should You Pick?
| Situation | Better choice |
|---|---|
| Casual app, low stakes | SSO: fewer passwords, provider's 2FA inherited automatically |
| Your email provider itself | Direct login, maximum hardening: it is the root of the whole tree |
| Financial accounts | Direct login with a unique password plus its own 2FA: keeps it independent of the shared basket |
| Privacy-sensitive services | Email login (or Apple's private relay): SSO tells the provider exactly which services you use and when |
| Anything you must never lose | Direct login: removes any dependency on a third account's continued survival |
For the direct-login accounts, unique passwords via a manager (our generator helps) and app based 2FA, which you can understand hands on with our free TOTP generator, cover the gap SSO would otherwise fill.
For Developers: The Two-Line Version
OAuth 2.0 with OpenID Connect is the standard stack: OAuth authorizes (what the app may do), OIDC authenticates (who the user is, via the ID token). Use authorization code flow with PKCE even for public clients, validate every token server side rather than trusting the browser, request the minimal scopes your app actually needs rather than the broadest available set, and let a maintained library handle the ceremony rather than hand rolling token exchange. Since your users' accounts are only ever as safe as your own login flow, add TOTP support too: our developer 2FA guide covers it, with test secrets available from our secret generator.
Frequently Asked Questions
Does the app see my Google password when I use Sign in with Google?
Never. You type your password only on Google's own page, inside Google's own domain; the app receives nothing but a token afterwards. If an app shows its own login fields asking directly for your Google password, that is phishing, not OAuth, and you should close it immediately.
Is "Sign in with Apple" different from the others?
Functionally similar under the hood, with one privacy addition: Apple offers relay email addresses, random forwarding aliases generated per app, so the service you sign up for never learns your real email address at all. A genuinely useful touch for privacy-sensitive signups you do not fully trust yet.
If I revoke an app's access, is my data deleted?
No. Revocation stops future access going forward; any data the app already collected before revocation lives on under that app's own privacy policy, and deletion requires asking the app directly, with regulations like GDPR helping where they legally apply.
Can I switch a "Sign in with Google" account to email login later?
Many services allow it: look for a "set a password" or "unlink Google" option inside account settings. Do this before ever closing or losing access to the provider account, or recovery turns into a lengthy support ticket adventure with no guaranteed outcome.
What happens to my SSO logins if the identity provider goes down?
New logins to every connected app fail until the provider recovers, since the redirect step has nowhere to go; existing, already established sessions usually keep working in the meantime. Rare in practice for providers the size of Google or Microsoft, but it remains a genuine reason critical services deserve an independent, non-SSO credential as a fallback.
