What Is OAuth? How "Sign In With Google" Actually Works

Short answer

OAuth is the protocol behind every "Sign in with Google/GitHub/Apple" button. It lets one app (e.g., a recipe site) ask another (e.g., your Google account) for permission to access specific data (e.g., your email address), without the recipe site ever seeing your Google password. The user approves once; the apps exchange tokens from there on.

The three parties

• Resource owner — you, the user whose data the app wants.
• Client — the app requesting access (the recipe site).
• Authorization server — the account provider (Google, GitHub). Issues tokens.
• (Resource server — optional 4th party; the API the token grants access to. Often same as auth server.)

The standard flow (Authorization Code + PKCE)

1. You click "Sign in with Google" on the recipe site.
2. Recipe site redirects you to Google, including: its client ID, the scopes it wants (e.g., email profile), a redirect URI, a random state value, and a PKCE code challenge.
3. Google shows the consent screen: "Recipe Site wants access to your email and profile. [Allow] [Cancel]."
4. You click Allow. Google redirects back to the recipe site's redirect URI with a short-lived authorization code.
5. Recipe site's backend exchanges the code (plus its client secret and PKCE verifier) for an access token and optionally a refresh token.
6. Recipe site calls Google's API with Authorization: Bearer <access_token> to fetch your email.

The tokens

Token	What it is	Lifetime
Authorization code	Short-lived proof-of-consent	~60 seconds
Access token	Used to call the API	Minutes to hours
Refresh token	Used to get a new access token	Days to months
ID token (OpenID Connect)	JWT about the user (email, name, sub)	Short

OAuth ≠ authentication

OAuth is authorization — granting access to resources. Authentication — proving who someone is — is what OpenID Connect (OIDC) layers on top of OAuth. OIDC adds an ID token, which is a JWT about the user. "Sign in with X" flows are always OAuth + OIDC, never OAuth alone. Decode any OIDC ID token with JWT decoder.

The four main "grant types"

• Authorization Code (+ PKCE) — the standard flow for web and mobile apps. PKCE is mandatory for public clients.
• Client Credentials — server-to-server; no user involved. Used when an app accesses its own resources.
• Device Authorization — for TVs, CLIs, IoT devices without a browser. User visits a URL on their phone to approve.
• Refresh Token — exchange a refresh token for a new access token without re-asking the user.

Common security traps

• Never put tokens in URLs — they'd leak into logs, referer headers, browser history.
• Always validate the state parameter — prevents CSRF on the redirect.
• Use PKCE even for confidential clients — it's cheap insurance.
• Store refresh tokens server-side, never in localStorage.
• Scope down aggressively — ask for only the permissions you actually need.

Related tools

OAuth state parameters and authorization codes often appear URL-encoded — URL encoder/decoder. PKCE verifiers are Base64URL-encoded random bytes — generate with Base64. ID tokens are JWTs — inspect with JWT decoder.