Navigating the Evolution of API Authentication

Every API has to answer one question on each request: who is calling, and are they allowed to do this? The methods for answering it have changed a great deal, from passwords sent with every call to short-lived tokens, OAuth flows and certificates. This guide explains the methods still worth using in 2026, which ones to retire, and the practical rules that keep an API safe, whichever you choose.

1. Authentication and authorisation

Authentication proves who the caller is. Authorisation decides what that caller may do. Most API security failures are authorisation failures: an authenticated user reads another customer's record simply by changing an ID in the URL. Whatever login method you pick, check on every request that the caller owns or may access the object it asks for.

2. The methods at a glance

3. API keys

An API key identifies a calling application. It is simple and fast, which is why it remains the most common method for server-to-server integrations.

Good practice:

• Generate keys with a cryptographically secure random generator, at least 32 bytes.
• Send them in a header, never in the query string. URLs end up in server logs, proxy logs, caches and browser history.
• Store only a hash of each key on the server, as you would a password, and show the full key to the user once.
• Give each key only the permissions it needs, and let users create separate keys per integration so one can be revoked alone.
• Support rotation: allow two valid keys at once so a client can switch without downtime.
• Never put an API key in front-end JavaScript or a mobile app. Anyone can read it there.

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

4. OAuth 2.0 and OpenID Connect

OAuth 2.0 lets a user grant an application limited access to their data without sharing their password. The application receives an access token with a set of scopes and a short lifetime, and often a refresh token to get a new one.

Which flow to use today:

• Authorization code with PKCE for every app a user signs in to: web apps, single-page apps and mobile apps. PKCE stops an intercepted code from being used by anyone else.
• Client credentials for a backend service calling another service with no user involved.
• Device authorization for TVs, command-line tools and devices without a browser.

The implicit flow and the resource owner password flow are deprecated by current OAuth security guidance and dropped from the OAuth 2.1 draft. Don't use them in new work.

OpenID Connect (OIDC) adds sign-in on top of OAuth 2.0. It returns an ID token, a JWT that tells your app who the user is. Use the ID token to start the user's session in your app; use the access token to call APIs. Don't send the ID token to an API as if it were an access token.

For browser apps, the safest pattern is a backend-for-frontend: your server completes the OAuth flow, keeps the tokens, and gives the browser only a session cookie marked HttpOnly, Secure and SameSite. Tokens kept in localStorage can be stolen by any script injected into the page.

5. JSON Web Tokens (JWT)

A JWT has three Base64URL-encoded parts: a header, a payload of claims, and a signature. It is signed, not encrypted, so anyone holding the token can read the payload. Never put secrets or personal data in it.

When you verify a JWT:

• Accept only the algorithm you expect, for example RS256 or ES256, and reject none. Don't let the token's header choose the algorithm.
• Check the signature, the expiry (exp), the issuer (iss) and the audience (aud) every time.
• Keep access tokens short-lived, for example 5 to 15 minutes, and use refresh tokens for longer sessions. A JWT cannot be revoked before it expires unless you add a deny list.
• Prefer asymmetric keys (RS256, ES256, EdDSA) when several services verify tokens, so only the issuer holds the signing key. Publish public keys at a JWKS endpoint and rotate them.

Use a well-maintained library for your language rather than parsing tokens yourself.

6. Mutual TLS and request signing

Mutual TLS (mTLS) makes the client present its own certificate during the TLS handshake. The server knows which machine is connecting before any request is read. It suits banking-grade and internal service links, and it can bind OAuth tokens to a certificate so a stolen token is useless elsewhere.

Request signing computes an HMAC over the method, path, timestamp and body with a shared secret. The receiver recomputes it and compares. AWS Signature v4 and most webhook providers work this way. Include a timestamp and reject old requests to stop replays, and compare signatures in constant time.

7. Methods to retire

• Basic authentication for public APIs: acceptable only over HTTPS for internal tools. Prefer keys or tokens.
• Digest authentication: relies on weak hashing and adds little over Basic with TLS.
• OAuth 1.0a: replaced by OAuth 2.0 almost everywhere.
• The OAuth implicit and password grants: use authorization code with PKCE instead.
• Hawk, SAML bearer assertions and NTLM for new HTTP APIs: niche or legacy. Use them only where an existing system requires them.

8. Rules that apply to every method

For people signing in to a dashboard rather than calling an API, add a second factor. Passkeys (WebAuthn) are the strongest option now widely supported by browsers and phones.

9. Running this on Domain India

• App Platform: Node.js apps are detected automatically; other languages run from a Dockerfile. Keep API keys and client secrets in the app's Env Vars tab, not in your repository. See Getting started with the App Platform.
• Shared hosting (PHP): some PHP functions that HTTP client libraries depend on are disabled on our shared servers, so an SDK that calls external APIs may fail. Check PHP disabled functions on shared hosting before you rely on one. Store secrets in a config file outside public_html.
• VPS: self-managed with root access, so you can run your own identity provider, gateway or mTLS setup.

Shared hosting and App Platform plans include free SSL, so your API can be served over HTTPS from the start.

Ready to deploy your API? Start with App Platform for Node.js or Dockerised services, or a VPS if you need full control of the server.