What is API Access? Keys, OAuth and Tokens

What is API access?

API access is how an API decides who may call it and what each caller may do. A client proves its identity with a credential such as an API key or an access token (authentication), and the API checks that identity's permissions for the requested action (authorization). It also makes per-consumer rate limits, billing and audit logs possible.

Authentication vs authorization

• Authentication (AuthN): who is calling? A valid key or token answers this.
• Authorization (AuthZ): is this caller allowed to do this? A valid key can still be refused on DELETE /orders/42 because it only has read permission.

You need both. Many real incidents are not stolen passwords but missing authorization checks on an endpoint that trusted any valid credential. For the security side, see API security.

Common ways to control API access

API keys

A long random string issued to each consumer and sent in a header such as X-API-Key. Simple to build and fine for server-to-server calls, but whoever holds the key has everything the key allows, and a leaked key works until you rotate it. Details in what is an API key.

OAuth 2.0 access tokens

OAuth 2.0 (RFC 6749) lets a client obtain limited access to an API. The access token is a credential for protected resources and carries a specific scope and lifetime. A user grants access in the Authorization Code flow, while the Client Credentials flow lets a confidential client such as a backend service get a token with its own credentials.

JWTs

A JSON Web Token is a signed token format, often used for OAuth access tokens, that carries claims such as the subject, scopes and expiry. The API can verify the signature without a database lookup. The flip side: a JWT stays valid until it expires, so revoking one early needs extra infrastructure, and its payload is readable by anyone who holds it, so never put secrets inside. You can inspect a token's header and payload with the free JWT decoder.

Bearer tokens

Not a separate mechanism but the way most tokens are sent: Authorization: Bearer <token>. Whoever bears the token gets access, so it must travel over HTTPS only. See bearer token.

Mutual TLS (mTLS)

Client and server both present X.509 certificates in the TLS handshake, so the certificate is the identity. It is strong for service-to-service traffic but costly to operate and awkward for browsers. RFC 8705 describes how OAuth clients use it and how access tokens can be bound to a client certificate.

An example request

GET /v1/orders HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOi...

HTTP/1.1 200 OK        (valid token, scope orders:read)
HTTP/1.1 401 Unauthorized  (missing or expired token)
HTTP/1.1 403 Forbidden     (valid token, missing scope)

401 means the API does not know who you are, 403 means it knows and says no. Telling them apart saves a lot of debugging.

Best practices

• Least privilege. Issue narrow scopes, not all-access credentials.
• Short-lived tokens. Use short access tokens with refresh tokens that you can revoke.
• Rotate and separate. Rotate keys on a schedule and use different credentials per environment.
• Header, not URL. Keys in query strings end up in logs, browser history and proxies.
• Per-consumer rate limits. One client's bug should not become everyone's outage.
• Log the identity. Without it you cannot tell what a leaked key touched.
• Document auth well. Show full example requests and what each 401 and 403 means.

Common mistakes

• Authenticating but not authorizing every endpoint and object.
• Long-lived tokens with no way to revoke them.
• One key for dev and production.
• Secrets in client-side code, repos or support emails.
• No expiry handling in the client, so a normal expiry looks like an outage.

Testing and monitoring authenticated APIs

An API that works without a token proves nothing, so tests and checks must use real credentials. In LoadFocus API monitoring a check can send headers and OAuth bearer tokens and chain requests, for example log in, pass the token to the next call and verify each step. For load, a load test that skips authentication measures a path real users never take, and token issuance itself often becomes the bottleneck. Two guides cover this in depth: API performance testing with OAuth2 and OAuth2 load testing. See also API monitoring.

FAQ: API access

What is the difference between an API key and an OAuth access token?

An API key is usually a static secret tied to a consumer account. An OAuth access token is issued by an authorization server, is short-lived and carries scopes. Use keys for your own server-to-server integrations and OAuth when users grant a third-party app access to their data.

Are JWTs more secure than API keys?

They have different properties rather than being better. A JWT carries an expiry and scopes and can be verified without a lookup, but it is hard to revoke before it expires. A key is easy to revoke but never expires on its own. Security depends mostly on how you store, scope and rotate either one.

How do I revoke a leaked JWT?

Either keep a server-side deny list and check it on every request, which gives up the stateless benefit, or keep access tokens short-lived so a leaked one expires quickly and revoke the refresh token instead.

What does 401 vs 403 mean?

401 Unauthorized means the request lacks valid authentication. 403 Forbidden means the caller is authenticated but not allowed to perform the action.

When should I use mTLS?

When both sides are services you control and you want certificate-based identity, or when a compliance requirement asks for it. Avoid it for browser clients, where certificate management is impractical.

How do I load test an API that needs authentication?

Use a dedicated test account or OAuth client, obtain the token as part of the test and reuse it across requests, and keep the test within the limits of that account. Never use production user credentials.