The API authentication decision looks like a product choice and almost never is. By the time a team is comparing vendors they have usually already made the three decisions that matter, by accident: what the credential is, what it is allowed to do, and how fast you can take it away. Those are design decisions, and the wrong ones cost you a migration that involves every customer who ever integrated with you.
The specific pain is predictable. A key leaks in a public repository and you discover you cannot rotate it without breaking the integration, because the customer only ever configured one and your system only accepts one. Or a second product ships and the scope names you chose for the first one turn out to describe screens rather than resources, so nothing composes. Or you revoke a token during an incident and it keeps working for another few minutes because a cache somewhere is holding an introspection result, and nobody can tell you how many minutes.
This guide leads with the patterns because the patterns pick the product. Once you know whether you need client credentials with real scopes or a long-lived key with a rotation story, the shortlist writes itself.
Key takeaways
- Rotation is a design property, not an operation. If your system accepts exactly one credential per customer, you cannot rotate without downtime, and no vendor fixes that after the fact.
- Scopes named after resources and actions survive a second product. Scopes named after features, screens or teams do not, and renaming them is a breaking change for every integrator.
- Every revocation has a propagation delay, because something is caching either a JWT until expiry or an introspection result. Know the number, state it, and make it a deliberate choice.
- API keys, OAuth client credentials and mTLS are not a maturity ladder. They answer different questions, and picking the fanciest one for a simple integration is how you end up with a support queue full of certificate problems.
Three credential models and the failure that picks each
Start with what the credential proves and what breaks when it leaks.
API keys. A long, random, opaque string the client sends on every request. The client does nothing cryptographic; it just holds a secret. This is the right answer far more often than architecture diagrams suggest, because it is the only model a customer can wire up in five minutes with curl, and integration friction is a real cost you pay in every deal.
The failure mode that rules keys out: the key is a bearer secret with no expiry, so anyone who reads it is you, forever, until a human notices. Keys end up in commit history, in support tickets, in screenshots, in log files that recorded the whole request header. If your API can move money or read regulated data, a credential with no expiry and no audience binding is a liability that grows quietly.
The failure mode that rules keys in: your integrators are a long tail of small customers with no security engineering, and every additional step in the setup flow loses some of them. A key they paste into a settings field ships. An OAuth client credentials flow with a token endpoint and a refresh loop does not.
OAuth 2.0 client credentials. The client holds a client ID and secret, exchanges them at a token endpoint for a short-lived access token, and sends that token on requests. The secret stays in one place and moves rarely; the thing on the wire expires on its own.
This is what you want when the credential should be scoped and short-lived, when multiple services need different permissions against the same API, or when you need a standard your customers’ platform teams already have libraries for. The cost is real: your integrators now have to implement token caching and refresh, and the ones who do it badly will hammer your token endpoint once per request and then complain about rate limits.
mTLS. Both sides present certificates during the TLS handshake, so the client is authenticated by key material it proves possession of rather than a secret it transmits. Nothing bearer-shaped crosses the wire, which means a captured request cannot be replayed by an attacker who did not also steal a private key.
mTLS picks itself when the caller is a known, small set of machines rather than a long tail of customers: partner banks, internal service-to-service traffic inside a mesh, regulated integrations where the requirement is written down. It is the strongest model here and the most expensive to operate, because you have inherited certificate lifecycle management. Expiry is now an outage class. Every team that deploys mTLS without automated renewal eventually takes a production incident at a timestamp nobody scheduled.
The honest summary: keys optimise for adoption, client credentials optimise for scoping and expiry, mTLS optimises for cryptographic assurance at the cost of operations. Many APIs correctly run two of these at once for different caller populations.
Key rotation without breaking your customers
The property that makes rotation possible has to exist before you need it, and it is simple: more than one credential can be valid at a time.
If your data model has a single api_key column on the customer record, rotation is a coordinated outage. The customer updates their config at the same instant you update your row, and anything in flight fails. Nobody does this on a Friday, which means nobody does it, which means the key from 2019 is still in production.
The model that works is a credentials table with many rows per customer, each with its own identifier, a created timestamp, an optional expiry, and a last-used timestamp. Then rotation becomes a customer-driven, zero-downtime sequence: issue a second key, deploy it wherever the old one lives, watch the old key’s last-used timestamp go cold, revoke it. Nobody coordinates anything.
Four details make the difference between that working and that being theatre.
Store a hash, not the key. Treat the key exactly like a password: show it once at creation, store only a hash, and make the recovery path “issue a new one” rather than “look up the old one”. If your support team can read a customer’s key out of an admin panel, your key is not a secret, and neither is your support team’s session.
Prefix keys with a public identifier. A key that starts with a short recognisable prefix plus a non-secret identifier lets you look up which credential is which without the secret, lets secret-scanning services recognise your format and notify you when one lands in a public repository, and lets your logs record which key was used without recording the key.
Record last-used, and expose it. The reason nobody retires old credentials is that nobody can prove they are unused. A visible last-used timestamp turns “we think this is dead” into “this has not been used in weeks”, and that is what makes a customer comfortable clicking revoke.
Expire by default, even if long. A credential with an expiry forces the rotation path to be exercised while everyone is calm. A credential with no expiry guarantees the first rotation you ever perform happens during an incident, with an engineer who has never done it before.
Needs first-hand data: Instrument your own credential table and record the age distribution of every key currently in use, plus what share of keys have never been rotated since creation. That distribution is the real measure of whether your rotation story works, and it is usually much worse than teams expect.
Scope design that survives contact with a second product
Scopes look easy until the day your company ships something else. Then you find out whether you designed permissions or named buttons.
The rule that holds up: scopes name a resource and an action, in that order, and nothing else. invoices:read, invoices:write, webhooks:manage. Not billing_dashboard, not admin, not integrations_team_access. A scope named after a screen dies when the screen is redesigned. A scope named after an internal team dies at the next reorg. A scope named after a resource survives both, because resources are what your API actually exposes.
Four traps worth naming.
Read and write are not enough. The moment you have a destructive operation, someone wants a credential that can create but not delete. If write covers both, you cannot offer it without inventing a second scope later and breaking the meaning of the first. Split delete out early or accept that you never can.
Wildcards are forever. A * scope, or an implicit “all scopes” for legacy keys, means you can never add a new scope that an existing credential should not have, because every wildcard credential silently acquires it. New capabilities need new opt-in scopes, which means wildcards have to be resolved into an explicit set at issue time rather than evaluated at request time.
Scopes are coarse; authorization is fine. A scope answers “is this client allowed to call this endpoint class”. It does not answer “may this client read this invoice”. Object-level checks belong in your authorization layer, against the resource, in the request path. Teams that try to encode per-object permissions as scopes end up with tokens too large to fit in a header.
Audience matters as much as scope. A token minted for your billing API should not be accepted by your admin API, even with the same scopes. Bind the audience at issue and verify it on receipt. Without that, a compromised low-value service becomes a credential source for a high-value one.
Design the scope taxonomy once, in a document, with the second product imagined. The renaming cost after launch is not yours, it is every integrator’s, and that is the kind of breaking change that eats a quarter.
Revocation propagation delay, and why it is never zero
When someone asks “how fast can we kill a leaked credential”, the honest answer is a number, and most teams do not know theirs.
Self-contained JWTs. The API verifies a signature and reads claims. No lookup, so no network cost and no shared state. Also no revocation: the token is valid until exp, full stop. Your revocation delay equals your token lifetime. Shortening the lifetime shortens the window and increases token endpoint load proportionally, which is the entire tradeoff and the same one described in session management.
Opaque tokens with introspection. The API calls the authorization server to ask whether the token is still good. Revocation is instant in principle. In practice nobody introspects on every request, because that puts a synchronous dependency on the authorization server in front of every API call, so gateways cache introspection results. Now your revocation delay equals the cache TTL, and it is distributed across however many gateway nodes you run.
The deny list. The compromise most teams reach: keep JWTs for speed, and check a small, fast, shared set of revoked identifiers on each request. Delay becomes replication lag of that set rather than token lifetime. It is a real improvement and it introduces a new dependency whose availability now gates your API, so it needs a defined failure mode. Fail-open keeps you up and lets revoked tokens through. Fail-closed is safe and turns a cache outage into an API outage. Pick deliberately and write it down.
Three things to establish for your own system, in writing, before an incident:
- The worst-case time between clicking revoke and the last node rejecting the credential, including cache TTLs at every layer.
- Whether revocation is fan-out (push to every node) or pull (nodes refresh on a timer), because the first is fast and fragile and the second is slow and reliable.
- What happens to in-flight long-lived connections. A revoked credential on a streaming or websocket connection is often not re-checked at all until reconnect, and that is a gap teams discover during their first real key compromise.
Needs first-hand data: Run a revocation drill in staging. Revoke a live credential while it is being used across every gateway node and record the elapsed time until the last node returns a rejection. Repeat with a warm cache and a cold one. That measured worst case is the number to publish in your security documentation, not the vendor claim.
OAuth 2.0 client credentials: a standard, not a product
Several products below implement this. It is worth separating the spec from the implementations, because the spec is what your integrators’ libraries already understand.
What it gives you
- A defined token endpoint and grant type, so any standard OAuth client library can authenticate against your API without custom code
- Short-lived access tokens by design, which bounds the damage from a leaked token without any revocation infrastructure
- Scopes and audience as first-class parameters, so least privilege is expressible in the protocol rather than in your application logic
- Introspection and revocation endpoints defined by companion specs, so those behaviours are interoperable rather than vendor-specific
What it does not do
- It says nothing about how you store or hash the client secret, or how many secrets a client may have, which is the rotation design above and entirely yours
- Token format is not specified. A compliant server may issue an opaque string or a JWT, and code that parses an access token is coupled to a specific implementation.
- It does not define your scope taxonomy, and a badly named scope is a protocol-compliant mistake
- It does not solve object-level authorization, rate limiting, or quota, all of which live in your API or gateway
mTLS: a standard, not a product
Mutual TLS is a TLS feature, not something you buy, though plenty of products help you operate it.
What it gives you
- Authentication by proof of private key possession, so nothing replayable crosses the wire and a captured request is useless on its own
- A client identity available at the connection layer, before any application code runs, which lets a gateway or mesh reject unknown callers cheaply
- A credential bound to a certificate chain, so trust decisions can be delegated to a certificate authority you control
- Strong alignment with regulatory requirements that specify mutual authentication for partner integrations
What it does not do
- It authenticates a client, not a user, and it carries no scopes. Authorization still has to happen above it.
- It gives you a certificate lifecycle to run. Renewal, distribution, revocation lists and clock skew all become your operational problem.
- Certificate expiry is an outage, and it will happen at least once before renewal is automated
- It is impractical for a long tail of small integrators, who cannot manage client certificates and will not try
Auth0
Auth0 is a mature, full-featured authorization server, and its machine-to-machine story is one of the most complete available as a service. You register APIs as audiences, define scopes on them, authorize client applications against those audiences, and get client credentials tokens with the audience and scope claims already correct. The extensibility hooks let you add custom claims at issue time, which is how most teams attach a tenant identifier to a machine token.
What you are buying is not the protocol, which is standard, but the operational surface: the admin UI where someone who is not you can see which clients hold which scopes, the logs, and the certifications an enterprise security review will ask for.
Pros
- Audience-scoped APIs are a first-class object, so binding tokens to a specific API is configuration rather than convention
- Machine-to-machine clients, their scopes and their grants are visible and auditable in an admin UI, which matters when the client list outgrows a spreadsheet
- Custom claims at token issue let you carry tenant and entitlement context without a lookup in every service
- Broad compliance and certification coverage, which shortens enterprise security review
Cons
- Machine-to-machine tokens are metered separately from user authentication, so a chatty service that requests a token per call becomes expensive fast
- Cost scales in a way that punishes exactly the architecture you want, which is many small scoped clients rather than one broad one
- It is a hosted authorization server in your request path, so its availability is your availability unless you cache aggressively
- Migration away means reissuing every client credential, which is a coordinated change across every integrator, as covered in Auth0 alternatives
Best for: Teams who want a managed authorization server with a real admin surface for machine clients and can afford per-token machine-to-machine pricing.
Pricing: Separate metering for machine-to-machine tokens from user-based plans, typically as a bundle of tokens per month with overage, on top of the tenant plan.
Okta
Okta’s relevance to API authentication runs through its custom authorization servers, which let you define your own audiences, scopes and claim rules and issue tokens for service clients. It is the same engine that handles workforce identity, which is both the appeal and the constraint: if your organisation already standardised on Okta for employees, putting API credentials in the same directory means one place where access is granted and one place where it is removed.
That last point is underrated. The highest-value thing an identity platform does for API auth is make offboarding complete. A service account created ad hoc in an API gateway outlives the engineer who made it; one created in the platform that runs your joiner-mover-leaver process does not.
Pros
- Custom authorization servers give you per-API audiences, scopes and claim rules without running the server yourself
- Service credentials live in the same governance and access review process as workforce identity, so offboarding actually reaches them
- Extensive policy engine for conditional access, which can apply to machine clients as well as people
- Enterprise-grade audit logging that satisfies the evidence requests compliance reviews generate
Cons
- Priced and packaged for workforce identity, so using it purely as a machine-to-machine authorization server is buying far more product than you need
- Configuration surface is large, and custom authorization server policies are easy to get subtly wrong in ways that only appear as a missing claim
- Workforce and customer identity are genuinely different products with different pricing, and conflating them is the most common buying mistake, as covered in Okta alternatives
- Heavier administrative overhead than a developer-oriented service for a team that only needs client credentials
Best for: Organisations already running Okta for workforce identity who want service credentials inside the same governance and deprovisioning process.
Pricing: Per-user subscription with API access management as a separately licensed add-on, contracted annually.
WorkOS
WorkOS is the odd entry here and it is worth being direct about why. Its centre of gravity is user-facing enterprise identity: SAML, directory sync, admin portals, the things covered in enterprise SSO. It is not a general-purpose authorization server for machine-to-machine credentials, and choosing it for that reason alone would be a mistake.
Where it becomes relevant is the adjacent problem. B2B products that issue API credentials to customers usually also have to let the customer’s IT admin manage those credentials, tie them to an organization, and remove them when an employee leaves. WorkOS gives you the organization and directory model that makes those credentials belong to something governed rather than floating loose.
Pros
- Organization and directory model gives customer-issued credentials an owner, which is what makes deprovisioning possible at all
- Admin portal lets customer IT teams manage their own configuration without an engineer from your side on every call
- Standards-based token issuance through AuthKit means the user-facing and machine-facing sides use compatible formats
- Clean, narrow API surface compared with the large platforms, which keeps integration small
Cons
- Not designed as a machine-to-machine authorization server, so scope taxonomies, per-API audiences and token introspection are not its strength
- Enterprise connections carry a per-connection cost, which is the wrong shape if your API credentials outnumber your enterprise customers
- Choosing it for API auth specifically means adopting a product whose roadmap is pointed somewhere else
- Less control over token lifetime and claim structure than a dedicated authorization server
Best for: B2B SaaS teams who already use WorkOS for enterprise SSO and want customer API credentials governed by the same organization and directory model.
Pricing: Free tier for core auth with enterprise connections priced per connection per month and directory sync billed separately.
Ory Hydra
Ory Hydra is the purest answer on this list to “I need a certified OAuth 2.0 and OpenID Connect server and nothing else”. It deliberately does not manage users, does not store passwords, and does not render login screens. It issues, validates and revokes tokens, and delegates the human parts to your own login and consent application over a defined interface.
That separation is exactly right for API authentication, where there is often no human at all. A client credentials flow through Hydra never touches the login app. And because it is stateless in the request path and written to scale, it is a reasonable component to put in front of a high-volume API without inheriting a user directory you did not want.
Pros
- Certified OAuth 2.0 and OIDC implementation, so interoperability with customer libraries is a solved problem rather than a debugging exercise
- Deliberately has no user database, which means no identity data to migrate and no opinion about your user model
- Self-hosted, so the token endpoint is in your infrastructure and its availability is yours to engineer rather than a vendor dependency
- Supports both opaque tokens with introspection and JWT access tokens, letting you choose your revocation delay explicitly
Cons
- You operate it: database, upgrades, high availability, and the on-call rotation for the service that gates every API call
- The login and consent application is yours to write, which is real work even when no human is involved in your primary flow
- The Ory product family spans several components and figuring out which pieces you need is a project in itself
- No admin UI experience comparable to the hosted platforms, so visibility into who holds what comes from what you build
Best for: Teams who want a standards-certified OAuth server in their own infrastructure, with no user directory attached, and have the operational capacity to run it.
Pricing: Open source and free to self-host at infrastructure and operational cost, with a managed network offering priced on usage for teams who want it hosted.
Zitadel
Zitadel is a full identity platform built around an event-sourced core, which gives it an unusual property for this category: every change to a credential, grant or scope is an immutable event rather than a row update. For API authentication that turns audit from a feature into a consequence of the architecture, and “who granted this service account that scope and when” is a query rather than a forensic exercise across log files.
It supports service users as first-class objects with their own keys and client credentials, multi-tenancy through organizations, and both cloud and self-hosted deployment with the same code.
Pros
- Event-sourced core means the full history of every grant and credential change is queryable, which is what an audit actually asks for
- Service users are first-class rather than a special case of a human user, so machine credentials have their own lifecycle
- Multi-tenant organization model fits B2B products issuing credentials on behalf of customers
- Same software self-hosted or managed, so a data residency requirement does not force a different product
Cons
- Smaller ecosystem than the incumbents, so unusual integration problems mean reading source rather than finding an answer
- The event-sourced model is powerful and unfamiliar, and operating its storage at high write volume needs understanding you do not start with
- Self-hosting a stateful identity service in your API’s request path is a serious commitment, discussed further in self-hosted identity providers
- Feature depth in niche protocol corners trails the platforms that have been shipping for a decade
Best for: Teams needing auditable, multi-tenant machine credentials with a genuine self-hosting path and no per-token pricing.
Pricing: Open source and free to self-host, with a managed cloud priced on active users and objects rather than per token issued.
Keycloak
Keycloak is the open-source default for organisations that need a full-featured authorization server and cannot or will not send credentials to a vendor. It implements client credentials, token exchange, fine-grained authorization services, and both opaque and JWT tokens, with an admin console that predates most of its competition and shows it.
Its real profile in API authentication is high capability and high operational cost. A Keycloak cluster in your request path is a stateful Java service with a database, a cache layer, a realm configuration that is easy to drift between environments, and a major-version upgrade history that has broken people. It is entirely workable, and it is a system you own on a Friday night when a CVE lands.
Pros
- Very complete protocol coverage including token exchange, which is what you need when one service must act on behalf of another
- Fine-grained authorization services can evaluate resource-level policies inside the token server rather than in every API
- No per-token or per-client cost at all, which is the decisive factor for high-volume machine-to-machine traffic
- Mature admin console and a large body of production deployment experience to draw on
Cons
- Operationally heavy: clustering, cache configuration, database tuning and upgrades are all yours, and it sits in front of every request
- Realm configuration drifts between environments unless you export and version it deliberately, and drift in an auth server is a security incident waiting to happen
- Major version upgrades have historically required real migration work rather than a rolling restart
- Admin UI and defaults are dense, and the distance between working and correctly configured is larger than it looks
Best for: Organisations with the platform capacity to run a stateful identity service and a strong reason that credentials cannot leave their infrastructure.
Pricing: Open source with no licence cost, paid only in infrastructure and the engineering time to operate and upgrade it; commercial support is available through downstream distributions.
FusionAuth
FusionAuth occupies a useful middle position: a complete identity platform you can self-host, with a licensing model that does not charge per user in its self-hosted community form, and a deployment story considerably lighter than Keycloak. For API authentication it supports client credentials, JWT and opaque tokens, per-application key management and custom claims through its lambda hooks.
The thing that distinguishes it operationally is that it deploys as a single application with a database and not much else, which puts it within reach of teams that want self-hosting but cannot staff a platform team to run a cluster.
Pros
- Self-hosting is genuinely straightforward compared with the alternatives, which makes owning your authorization server realistic for a smaller team
- Per-application key and signing configuration, so different APIs can use different keys and lifetimes without separate deployments
- Lambda hooks let you shape token claims in code, which is how tenant context gets into machine tokens without a lookup
- Licensing is not per monthly active user in the self-hosted form, which suits machine-heavy workloads where the user count is meaningless
Cons
- Advanced features sit behind paid editions, so the free self-hosted version is a smaller product than the marketing surface
- Smaller community than Keycloak or the hosted platforms, so answers to unusual questions are thinner
- You are still operating a stateful service in the request path with the availability requirements that implies
- Ecosystem integrations and SDK breadth trail the larger vendors
Best for: Teams who want a self-hosted authorization server without a platform team, particularly where per-user pricing makes no sense for machine traffic.
Pricing: Free self-hosted community edition with paid editions unlocking advanced features, plus a managed hosting option priced by deployment size rather than per token.
Kong
Kong is a different layer of the problem and belongs here for that reason. It is an API gateway, so it sits in front of your services and enforces authentication at the edge: key auth, JWT validation, OAuth introspection, mTLS termination and rate limiting are all plugins. It does not issue credentials the way an authorization server does, but it is often where the credential is actually checked.
The gateway is also where your revocation delay gets decided, and most teams never look. Kong caches introspection results and JWKS documents by configuration, and those TTLs are your propagation window. If you run a gateway in front of an authorization server, the gateway’s cache settings matter more to your incident response than the authorization server’s revocation endpoint does.
Pros
- Enforcement happens at the edge, so your services can trust an already-validated identity instead of each reimplementing token checking
- Plugin coverage spans key auth, JWT, OAuth introspection and mTLS, so multiple credential models coexist behind one policy layer
- Rate limiting and quota sit in the same place as authentication, which is where they belong since both key off the same client identity
- Open-source core with a self-hosted path, so the enforcement layer does not have to be a vendor dependency
Cons
- It is not an authorization server: credential issuance, scope definition and the consent surface all live somewhere else
- Its caching of introspection and JWKS is a silent determinant of your revocation delay, and the defaults are chosen for throughput
- Running a gateway cluster is its own operational discipline, with configuration drift and upgrade risk in the path of all traffic
- The gap between the open-source core and the enterprise features teams actually want is wide enough to matter at buying time
Best for: Teams already running an API gateway who want authentication, rate limiting and quota enforced in one place rather than in every service.
Pricing: Open-source gateway free to self-host, with enterprise and managed offerings priced by services, nodes or request volume depending on the edition.
How to choose
Work down the list. Each answer removes options.
Who is calling? A long tail of small customers means API keys with a real rotation design, and anything else costs you integrations. A known set of partner systems or internal services means client credentials or mTLS, and the extra setup cost is affordable because there are few of them. Many APIs run both, and that is a correct answer rather than a failure to standardise.
What is the maximum acceptable revocation delay? Write the number down first. If it is minutes, a short-lived JWT with no lookup is fine and you should not build introspection infrastructure. If it is seconds, you need either introspection with a small cache TTL or a deny list with defined fail behaviour, and you need to accept the dependency that creates.
Where does the credential live? If regulation or your own risk posture says credentials cannot sit in a vendor database, the shortlist is Ory Hydra, Keycloak, Zitadel or FusionAuth, in roughly increasing order of how much operational help they give you. If a vendor is fine, the question becomes pricing shape, and machine traffic punishes per-token models hard.
What enforces it? Every service, or a gateway. Doing it per service means every team reimplements token validation and one of them gets it wrong. Doing it at a gateway means one correct implementation and one cache whose TTL you must own. Prefer the gateway, and go read its cache configuration.
| Option | Layer | Credential models | Self-host | Scales on |
|---|---|---|---|---|
| Auth0 | Authorization server | Client credentials, JWT | No | Machine tokens issued |
| Okta | Authorization server | Client credentials, JWT | No | Users, with API access add-on |
| WorkOS | User identity, adjacent | AuthKit tokens | No | Enterprise connections |
| Ory Hydra | Authorization server | Client credentials, opaque or JWT | Yes | Infrastructure only |
| Zitadel | Identity platform | Service users, client credentials | Yes | Users and objects |
| Keycloak | Authorization server | Client credentials, token exchange | Yes | Infrastructure only |
| FusionAuth | Identity platform | Client credentials, JWT | Yes | Edition and deployment |
| Kong | Gateway enforcement | Key auth, JWT, introspection, mTLS | Yes | Nodes or request volume |
| OAuth 2.0 / mTLS (standards, not products) | Protocol | Defined by spec | Not applicable | Not applicable |
Whatever you pick, three things are yours and no vendor supplies them: a credentials table that allows two valid keys at once, a scope taxonomy written down before the second product exists, and a measured revocation number you would be willing to publish. Get those right and the product choice is reversible. Get them wrong and it is not.
Frequently asked questions
Are API keys insecure?
Not inherently. A long random key, stored hashed, prefixed for identification, scoped, expiring, and rotatable without downtime is a defensible credential for most APIs. What is insecure is the common implementation: one permanent key per customer, stored in plaintext, with every permission and no expiry. The model is fine; the defaults people ship are not.
Should I use JWTs or opaque tokens for my API?
Decide by revocation delay. JWTs validate with no network call and cannot be revoked before expiry, so your delay equals your token lifetime. Opaque tokens with introspection revoke immediately in principle and in practice equal your gateway cache TTL. If you cannot tolerate a multi-minute window, you need introspection with a short cache or a deny list, and you need to decide what happens when that lookup fails.
Do I need mTLS?
Only if a specific requirement or threat model calls for it: regulated partner integrations, internal service-to-service traffic inside a mesh, or a small known set of high-value callers. It is the strongest option and the most expensive to operate, because you have taken on certificate lifecycle management and made expiry an outage class. For a long tail of customer integrations it is impractical.
How do I authenticate AI agents calling my API?
As machine clients with narrower scopes and shorter token lifetimes than you would give a human-driven integration, because an agent can make a very large number of calls very quickly after a prompt you did not write. The same scope discipline applies with more urgency, and the gateway layer is where per-agent quotas belong. The AI gateway category covers the enforcement side of this in detail.
Where should audit logging for API credentials live?
Not only in your authorization server. You want credential issuance, grant changes and revocations in the same searchable store as your application and gateway logs, because incident questions cross all three. Retention is usually the binding constraint rather than volume, and the options are covered in log management.
Related reading
- Best authentication providers for developers — the wider identity landscape and the build-versus-buy arithmetic.
- Best authorization and permissions services — object-level permission checks, which scopes deliberately do not cover.
- Best session management libraries — the same revocation tradeoff on the browser side.
- Best self-hosted identity providers — running the authorization server yourself, and what that costs.
- Best open source authentication solutions — the licensing and operational picture across the open options.
- Best enterprise SSO solutions for B2B SaaS — the human-facing half of the same platform decision.