Security
API keys vs OAuth vs JWT — picking the right auth
API keys, OAuth, and JWT get lumped together because on the wire they all look the same — some string sent in an Authorization header. But they're not alternatives to pick from a menu; they answer different questions. Confusing them leads to the classic mistakes: putting a secret API key in front-end JavaScript, or rolling your own login when OAuth already solved it.
API keys — "which app is this?"
A single static secret that identifies a caller (usually a whole application, not a person). Simple to issue, simple to check — the server compares it to what it has stored. Perfect for server-to-server calls and usage tracking. The rules: treat it like a password, send it only over HTTPS, keep it on the server, and never ship it in browser or mobile code where anyone can read it.
OAuth — "acting on whose behalf?"
Not a token format but a flow: it lets a user grant your app limited access to their account somewhere else — "Sign in with Google," "let this app read your GitHub repos" — without ever handing over their password. The user logs in at the real provider, which hands your app a scoped, revocable token. Reach for OAuth whenever a person is authorising access to their own data on another service.
JWT — "how does the server verify it?"
A JSON Web Token is a token format: a small, signed bundle of claims ("user 42, expires at 5pm"). Because it's signed with a secret only the server knows, the server can verify it's genuine and untampered by checking the signature alone — no database lookup per request. Great for scale; the trade-off is that a JWT is valid until it expires, so instant revocation takes extra work.
API key = a static password for an app. OAuth = a flow to act on a user's behalf without their password. JWT = a signed token the server trusts without looking anything up. Different jobs — often used together.
They stack
A real system frequently uses all three: OAuth runs the login flow, the token it issues is a JWT, and server-to-server calls between your own services use API keys. And none of them mean anything without the encrypted pipe underneath — HTTPS secures the transport; these decide identity and permission on top of it. Pick by the question you're answering, not by which string looks familiar.