API authentication: API key, session or OAuth?

Identity and permission are two separate decisions

Authentication checks a supplied credential and associates it with an identity. This may be a user, a service or an integration. If a credential is stolen, the system may still recognise its owner rather than the actual person at the other end. Protecting secrets, expiry and blocking access therefore belong to the procedure.

Authorisation then decides on the specific action. A signed-in user may, for example, read their own invoices but not anyone else's. Even a technically valid token with a general read scope does not determine which individual invoice is accessible. This check belongs at every affected data and function access. The OWASP REST guidance distinguishes access to the service from its access controls.

Plan two sets of evidence: one for access and one for object permissions. A successful login is only the first.

Find the right starting point

The table helps with selection; it is not a security ranking. An existing identity provider may also usefully centralise service access. Conversely, a small internal integration does not need a new authorisation server simply because OAuth is widespread.

OAuth Client Credentials is intended for confidential clients that can protect their own credentials. It is not an interactive user login. A browser application cannot keep an embedded client secret confidential. RFC 6749, sections 2.1 and 4.4, describes the basic client types and the service flow.

For browsers, draw the trust boundary first

With a server-side session, the browser typically holds a session identifier in a cookie. The server associates it with a session. This facilitates central revocation, but requires all relevant instances to take the current session state into account. Simply deleting a cookie in the browser does not necessarily end server-side access.

Another architecture lets the browser obtain OAuth tokens. Issuance, storage and use must then be designed for a public client. An application with its own backend can also manage tokens on the server and give the browser only a session. This choice changes the attack surfaces; it eliminates neither injected browser code nor the need for correct permissions.

For your setup, record which secrets JavaScript can read and which credentials the browser sends automatically. This leads to suitable cookie and CSRF protection. Different origins also require CORS. CORS does not replace authentication.

Distinguish API keys, bearer tokens and JWTs

An API key is defined by the service concerned. It may identify an application or account and be associated with permissions, quotas and expiry. Its properties follow the provider's or your own API contract, not a universal API key standard. Treat a secret key as a transferable credential. The API key guide explains its practical management.

With a bearer token, possession is generally sufficient for use within its validity and permissions. TLS protects transmission but does not prevent use of a string copied elsewhere. RFC 6750 describes this property. Sender-constrained mechanisms can meet particular requirements; they need a suitable overall profile, not an extra arbitrary header.

A JWT contains structured statements called claims. A signed variant allows origin and integrity to be checked within the agreed trust model. It does not automatically encrypt the content. An opaque token, by contrast, is a string the client should not interpret. Both can be access tokens. What matters is how the receiving service validates them and what it subsequently permits. JWT validation explores this step.

HTTP Basic transmits a user identifier and password encoded in Base64; this encoding is not encryption. Existing integrations can use it over TLS, but bring reusable credentials into the request path. New user delegation should not be built by having third-party applications collect the user's main password. See RFC 7617, sections 1 and 4.

Test your choice against a small scenario

Suppose an archive service needs to retrieve approved documents at night. It needs neither a user interface nor permission to change documents. Dedicated service access with limited read permission is reasonable; a shared administrator key would not be. Later, a partner application needs to retrieve documents approved by individual users. This creates a different task: separate grants, their scope and their revocation must be representable. Delegated OAuth access should be considered for this purpose.

Before implementation, prepare a short decision record covering client type, protected resources, permission scope, expiry, blocking mechanism and owner. Use maintained protocol libraries or established provider features. For OAuth, current security choices follow RFC 9700: older examples using the password grant or an unprotected code flow are unsuitable templates.

In your own test environment, permitted access must not be the only thing that works. Expired or blocked access, a token for another API and a forbidden action must be reliably rejected. Log the decision and a correlation identifier, not the complete credential.

Rollout, rollback and next steps

Start by migrating a clearly defined group of clients. Record how new credentials are distributed, old ones disabled and errors detected. A limited period of parallel operation only makes sense if both paths enforce the same intended permissions. Rollback uses a tested previous configuration with credentials that remain trustworthy. A known compromised key is not reactivated.

The API Security Check does not examine this authentication and authorisation flow. It requires configuration and code review, plus controlled tests with your own identities. After making your choice, start with OAuth/OIDC, API keys or browser cookies. Sources for this guide checked: 27 September 2026.

Next steps