"Sign in with Google" is OpenID Connect; "let this app read my calendar" is OAuth. Access tokens, refresh tokens and ID tokens do different jobs, and mixing them up causes most auth bugs. The authorization code flow with PKCE, what each token is for, and the mistakes we see in fast-built apps.
OAuth 2.0 (RFC 6749) lets an app act on a user's behalf at another service without seeing their password. OpenID Connect is a layer on top that also tells the app who the user is. Most "Sign in with..." buttons are OpenID Connect.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Your app creates a random secret (the code verifier) and sends a hash of it (the code challenge) when redirecting the user to sign in.
The user signs in at the provider, which redirects back with a short-lived authorization code.
Your app exchanges the code, plus the original verifier, for tokens. An attacker who intercepts the code cannot use it without the verifier.
PKCE (RFC 7636) was designed for mobile apps and is now recommended for every client, including server-side web apps. The older implicit flow, which returned tokens in the URL, should not be used; the OAuth 2.1 work removes it.
Sending the ID token to your API as if it were an access token. APIs should accept access tokens issued for them, and check the audience.
Not validating tokens: check the signature, issuer, audience and expiry on every request, using the provider's published keys.
Long-lived access tokens because refresh "was annoying". A leaked token then works for weeks.
Refresh tokens in localStorage in a browser app. Keep them server-side or in an HttpOnly cookie, and rotate them.
Redirect URIs with wildcards, which let an attacker receive the authorization code. Register exact URIs.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Passkeys for App Builders: What They Replace, What They Don't, and How to Roll Them Out
A passkey is a key pair: the private key stays on the user's device or in their password manager, and your server stores only the public key. Nothing to phish, nothing useful to steal from your database. How WebAuthn works, synced versus device-bound passkeys, account recovery, and a rollout that does not lock anyone out.
Read
Which API Keys Are Safe in Your Frontend? A Field Guide for Apps Built Fast
Everything in a browser bundle or mobile app is public, including any variable your framework inlines at build time. Which keys are designed to be public and what actually protects you when they are, which must never ship, and what to do in the first hour after one leaks.
Read
As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.