OAuth 2.0
The handshake that lets one app act on your account at another app, without ever seeing your password.
See it
What it is
OAuth 2.0 is the protocol for handing an app limited access to your account somewhere else without handing over your password. You get bounced to the provider (Google, GitHub, Stripe), you approve a list of scopes, and the provider redirects back with a one-time authorization code. The app then exchanges that code at the token endpoint for an access token it can use on your behalf. Access tokens are usually short-lived, though nothing in the spec requires it. The provider stays the only one who ever sees the credentials.
Reach for it whenever your product needs to touch someone else's data: reading a calendar, posting to a repo, pulling invoices. The flow you almost always want in 2026 is Authorization Code with PKCE, for browser apps and native apps alike. The old implicit flow is dead, and password grant is deader.
The big misconception: OAuth 2.0 is authorization, not login. It tells your app what it may do, not reliably who the human is. If you want identity ('this is user alice@example.com'), you want OpenID Connect sitting on top of it, which adds an ID token with verified claims. Second gotcha: redirect URIs must match exactly, down to the trailing slash, which is why local development breaks first.
Ask AI for it
Implement OAuth 2.0 Authorization Code Flow with PKCE against [provider]. Generate a code verifier and S256 challenge, include a random 'state' value and verify it on return, redirect to the provider's authorize endpoint with the minimum scopes needed, then exchange the code plus verifier for tokens on the server. Assume a backend-for-frontend shape: the browser talks to your server, your server talks to the provider, and tokens never reach client JavaScript. Store the access token and refresh token server side, never in localStorage, and refresh silently before expiry. If this is instead a public client with no backend of its own, say so explicitly, keep the verifier and the token call in the browser, and use no client secret anywhere. Register the exact redirect URI and handle the user-denied-consent case with a real error screen.