What Is API Authentication?
API authentication is the process of verifying the identity of a client making a request to an API. Without authentication, any person or system on the internet could call your API, read your data, and modify your records. Authentication answers the question: who is making this request?
Authentication is often confused with authorisation, which answers a different question: what is this caller allowed to do? Authentication comes first — you must establish identity before you can enforce permissions.
There are three authentication methods you will encounter in almost every modern API:
- API Keys — simple tokens passed with every request
- JWT (JSON Web Tokens) — self-contained tokens that carry identity claims
- OAuth 2.0 — a delegated authorisation framework for third-party access
API Keys
What Is an API Key?
An API key is a long, randomly generated string that acts as a password for your application. When you register for a service — a weather API, a payments API, a mapping API — you receive an API key. You include this key in every request you make to that service.
GET https://api.example.com/weather?city=London
Authorization: ApiKey sk_live_abc123xyz789Or as a query parameter (less secure, but common):
GET https://api.example.com/weather?city=London&apikey=sk_live_abc123xyz789How API Keys Work
The server receives the request, extracts the API key, looks it up in its database, and identifies which application or user the key belongs to. If the key is valid, the request proceeds. If not, the server returns a 401 Unauthorized response.
Pros and Cons of API Keys
| Pros | Cons |
|---|---|
| Simple to implement | No expiry by default |
| Easy for developers to use | Easy to accidentally leak (logs, URLs, repos) |
| Good for server-to-server calls | No user identity — identifies the app, not the person |
| Easy to revoke | Must be stored securely as a secret |
When to Use API Keys
API keys are best suited for server-to-server communication where your backend calls a third-party service. They should never be exposed in client-side JavaScript or mobile apps where users could extract them.
JWT — JSON Web Tokens
What Is a JWT?
A JSON Web Token (JWT) is a compact, self-contained token that encodes identity information (called claims) directly inside the token itself. Unlike API keys — which require a database lookup to identify the caller — a JWT carries its own payload that the server can verify without any database query.
A JWT looks like this:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjQyLCJlbWFpbCI6ImFsaWNlQGV4YW1wbGUuY29tIiwiZXhwIjoxNzA5MDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cIt is three Base64-encoded segments separated by dots:
- Header — the algorithm used to sign the token (e.g. HS256, RS256)
- Payload — the claims (user ID, email, roles, expiry time)
- Signature — a cryptographic signature that proves the token has not been tampered with
How JWT Authentication Works
- The user logs in with their email and password.
- The server verifies the credentials and issues a signed JWT.
- The client stores the JWT (in memory or local storage) and sends it with every subsequent request in the
Authorizationheader. - The server verifies the JWT's signature and reads the claims — no database lookup required.
GET /api/profile
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...Pros and Cons of JWT
| Pros | Cons |
|---|---|
| Stateless — no session database needed | Cannot be revoked before expiry without extra infrastructure |
| Carries user claims in the token | Payload is encoded, not encrypted — do not put sensitive data in it |
| Scales well across microservices | Token size is larger than a simple API key |
| Short-lived tokens limit exposure if leaked | Requires careful expiry and refresh token management |
When to Use JWT
JWT is ideal for user authentication in web and mobile applications. It is widely used in single-page applications (SPAs) and mobile apps where sessions need to work across multiple microservices or API servers without shared session storage.
OAuth 2.0
What Is OAuth 2.0?
OAuth 2.0 is not an authentication protocol — it is an authorisation framework that enables one application to access resources on behalf of a user, without the user sharing their password with that application.
You have used OAuth every time you clicked "Sign in with Google" or "Connect with GitHub." Instead of giving a third-party app your Google password, OAuth lets Google issue a limited-access token that the app can use on your behalf.
How OAuth 2.0 Works (Simplified)
- Your app redirects the user to the authorisation server (e.g. Google's login page).
- The user logs in and approves the permissions your app is requesting (e.g. "read your email").
- The authorisation server redirects back to your app with an authorisation code.
- Your app exchanges the code for an access token (and optionally a refresh token).
- Your app uses the access token to call the API on behalf of the user.
Key OAuth 2.0 Terminology
- Resource Owner — the user who owns the data
- Client — your application requesting access
- Authorisation Server — issues tokens (e.g. Google, GitHub, Auth0)
- Resource Server — the API that holds the protected data
- Access Token — a short-lived token that grants access
- Refresh Token — a longer-lived token used to obtain new access tokens
- Scope — the specific permissions the access token grants (e.g.
read:email)
Pros and Cons of OAuth 2.0
| Pros | Cons |
|---|---|
| Industry standard for delegated access | Complex to implement correctly from scratch |
| Users never share passwords with third parties | Many flows and grant types to understand |
| Granular permission scopes | Overkill for simple internal APIs |
| Tokens can be revoked by the user | Requires an authorisation server infrastructure |
When to Use OAuth 2.0
Use OAuth 2.0 when your application needs to access a third-party API on behalf of a user — connecting to Google Drive, posting to Twitter, reading GitHub repositories. Also use it when you are building a platform that third-party developers will integrate with. For internal APIs where you control both the client and server, simpler methods like API keys or JWT are usually sufficient.
OpenID Connect: OAuth 2.0 + Authentication
OAuth 2.0 alone does not tell your app who the user is — only that they granted access. OpenID Connect (OIDC) extends OAuth 2.0 with an identity layer, adding an ID token (a JWT) that contains the user's profile information. This combination is what powers "Sign in with Google" — OAuth for the access, OIDC for the identity.
Choosing the Right Authentication Method
| Scenario | Recommended Method |
|---|---|
| Backend calling a third-party service | API Key |
| User logging into your web or mobile app | JWT |
| Third-party app accessing user data on your platform | OAuth 2.0 |
| "Sign in with Google/GitHub/Facebook" | OAuth 2.0 + OpenID Connect |
| Microservices communicating internally | JWT or mTLS |
Security Best Practices
- Never commit API keys or secrets to version control. Use environment variables.
- Set short expiry times on JWTs (15–60 minutes) and use refresh tokens for longer sessions.
- Always transmit tokens over HTTPS — never plain HTTP.
- Validate the JWT signature on every request — do not trust the payload without verification.
- Use the principle of least privilege: request only the OAuth scopes you actually need.
- Rotate API keys regularly and immediately if you suspect a leak.
- Store tokens in memory or secure storage — avoid storing JWTs in localStorage where XSS can access them.
Testing Authentication With Mock APIs
When building authentication flows, you often need to test how your application behaves when the API returns a 401 or 403. Rather than manipulating a real auth server, you can create mock endpoints that simulate authenticated and unauthenticated responses instantly.
With Mockable, you can create a mock endpoint that returns a 200 with a valid-looking JWT payload for your success case, and a 401 with an error body for your failure case — giving your frontend team full control over authentication testing without needing a real auth server.
Conclusion
API authentication is not one-size-fits-all. API keys are simple and ideal for server-to-server integrations. JWT is the right choice for stateless user authentication in modern web and mobile apps. OAuth 2.0 solves the delegated access problem elegantly when third-party integrations are involved.
Understanding these three mechanisms puts you in a strong position to design secure, professional APIs. And when you need to test your authentication flows without a live backend, Mockable's free mock API lets you simulate any auth scenario in minutes.