Why the door needs a lock
In the previous guide, we established that an API is a messenger between two systems. But here's something we glossed over: most APIs aren't open to the public. If any app or person could call any API without restriction, the weather service's servers would be overwhelmed, payment systems would be chaos, and private data would be freely accessible to anyone who asked.
This is where authentication comes in. Authentication is the process of proving who — or what — you are before you're allowed to use an API. Think of it as the bouncer at the door: before you get access to the resource inside, you have to show some form of ID.
There's also a related concept worth knowing: authorisation (sometimes spelled "authorization"). Authentication asks "who are you?" Authorisation asks "what are you allowed to do?" They often happen together, but they're distinct steps. You might be authenticated as a valid user but not authorised to access certain parts of the system.
Authentication = proving your identity. Authorisation = confirming your permissions. Getting into a building requires authentication (the key card says who you are). Going to a restricted floor requires authorisation (your keycard also needs permission for that floor).
First: these terms aren't all the same kind of thing
The reason API auth vocabulary feels so confusing is that people use all these terms in the same breath — as if they're interchangeable alternatives. They're not. They're describing different layers of the same problem.
Keep this grid in mind as we walk through each method. The moment you know which category something belongs to, the definition becomes obvious.
The methods, from simplest to most sophisticated
Authentication has evolved over decades as the web got more complex. Walking through that evolution is the fastest way to make each method make sense.
API keys are simple and very common, especially for public APIs like maps, weather services, and payment integrations. One important nuance: an API key usually identifies the application, not an individual user. If you build a weather app using an API key, the key proves that your app is calling the weather service — not which specific person opened your app.
Think of the cookie like a hotel key card: the hotel made it, the hotel recognises it, and the hotel can deactivate it at any time. Your browser automatically sends that cookie back with every subsequent request, and the server checks its session records to confirm you're still logged in. This works well for websites, but it requires the server to store session data — which gets complicated when millions of users are logging in across hundreds of servers.
Technically, you send a bearer token in a request header:
Authorization: Bearer <token>. The server verifies the token and grants access if it's valid. Because the token itself carries all the information needed, the server doesn't need to store session data — it just checks the token. This is far easier to scale.The catch: because anyone who has the token can use it, bearer tokens must be protected carefully. This is why they're kept out of URLs, never logged, and — critically — why they expire. A stolen token that expires in 15 minutes is far less dangerous than one that lasts forever.
Because a JWT is self-contained — the user information is inside the token — the server can verify requests without looking anything up in a database every time. It reads the token, checks the signature, and knows who you are. This is why JWTs are popular in distributed systems where many servers need to verify the same tokens.
Think of it like valet parking. You hand the valet a special key that only unlocks the ignition — not the boot, not the glovebox. The valet can drive the car, but only within those limits. OAuth works the same way: you grant an app limited access to a specific resource (your Google Drive files, your GitHub repos) and that's all it can touch.
Technically, OAuth is an authorisation framework — it's about granting permissions, not verifying identity. It answers "what is this app allowed to do?" but on its own, it doesn't definitively answer "who is this user?"
When you click "Sign in with Google" on a website, OIDC is almost certainly what's running under the hood. Google authenticates you, confirms your identity to the third-party site, and the site logs you in — without ever storing your Google password.
Behind the scenes, SSO is usually implemented using protocols like OpenID Connect or SAML. The user experience feels seamless because those protocols are quietly passing your verified identity between systems. You don't see any of that — you just don't have to log in seven times.
Why there are two kinds of token
In most modern systems using bearer tokens, you'll encounter two tokens working together. This pairing is a deliberate security design — not an accident or an overcomplicated solution.
The logic: anything you use constantly (the access token, sent with every request) is exposed more often, so it should expire quickly. The refresh token is used rarely — just to renew — so it can live longer while being stored more carefully.
1. Never expose API keys or tokens publicly. That means not in frontend JavaScript, not in GitHub repos, not in URLs. Treat them like passwords. 2. Always use HTTPS. Early auth methods that sent credentials without encryption (like basic authentication) were vulnerable to anyone intercepting the connection — HTTPS prevents this. 3. Tokens expire for a reason. If your code breaks because a token expired, that's the security model working correctly — not a bug to route around.
Quick reference
Seven terms, plain English: