Recap: Authenticating API Clients

Choose the proof that suits the caller, check it fully, and know how you will cut it off.

Each method proves a caller differently, and differs most in how access is taken away.

Authentication is who is calling, and fails with 401; authorisation is what they may do, and fails with 403.
API keys name a project, travel in a header, and are revoked at once.
Bearer tokens let in whoever holds them, so they go only in Authorization over HTTPS and expire soon.
Sessions suit the API's own browser front end; tokens suit every other caller.
A JWT is signed claims: check algorithm, signature, issuer, audience and times, in that order.
Its payload is readable by anyone; keep secrets out.
Revoking a JWT early needs short lifetimes, a deny list or introspection.
Mutual TLS proves a service in the handshake, and suits services you run.

The five methods against the four questions
Method	Proof	Travels in	Suits	Cut off by
API key	A random secret	A header	Partner servers	Revoking it
Session	An id for server state	A cookie	Own browser front end	Deleting it
Bearer token	An issued token	Authorization	Apps for a user	Expiry or revocation
JWT	Signed claims	Authorization	Services verifying alone	Expiry, or extra checks
Mutual TLS	A certificate and key	The handshake	Own services	Not renewing it

← → move through sections and cards