OAuth 2.0, OpenID Connect and API keys

• OAuth 2.0 is delegated authorization: "let this app read my Google Calendar" without sharing your password.
• "Sign in with Google" is OpenID Connect (OIDC), a thin layer on top of OAuth that adds an ID token saying who you are.
• The benefit: users do not keep a password per app. They log in once at the identity provider (IdP).

1. The app redirects you to the IdP (Google) with client_id, scope, redirect_uri and a state value.
2. You log in and consent at Google, never at the app.
3. Google redirects back to the app with a short-lived code.
4. The app's backend swaps the code plus its client secret for tokens over a direct server-to-server call (the back channel).
5. The app receives an access token (plus an ID token and a refresh token) and uses them.

Why a code and not the token directly? The browser URL can leak (history, logs, referrers), so the real token never travels through it. Mobile and single-page apps have no safe place for a client secret, so they add PKCE: a one-time random verifier whose hash is sent up front and proven at the swap, so a stolen code is useless.

How does an API validate an opaque token? It cannot alone. It calls the IdP's introspection endpoint ({active, sub, scope, exp}, often cached briefly) or looks it up in a shared store. A JWT is verified locally with the public key. So: JWT = fast, stateless validation but hard to revoke. Opaque = a lookup per request but instant revocation.

• Identify an application or project, not a user. Mostly server-to-server.
• A static secret with no expiry by default, so a leaked key is a compromise until it is rotated. Keep keys server-side, never in client code, and rotate them.
• Typical uses: rate limiting, billing, quotas.
• Stronger options for service-to-service: the OAuth client credentials flow, or mTLS.
• A term heard in passing: "offline ticket". It is probably the refresh token, which OAuth issues with the offline_access scope so an app can get new tokens while the user is away.