An AI application rarely has one caller. It may serve a signed-in user, call several model providers, run an agent in the background, and let that agent access GitHub, Slack, or an MCP server.

Those actors should not share one credential. Authentication answers who is calling; authorization decides what that identity may do.

The short answer

Situation	Typical starting point	Why
Your backend calls a model provider	Server-side API key or workload identity	Simple machine-to-machine access
A user signs in to your AI product	Secure session, often backed by OIDC/OAuth	User identity and revocation
An agent accesses a user’s third-party account	OAuth with narrow scopes	Delegated, revocable permission
Internal services call each other	Workload identity or short-lived signed token	Avoid shared permanent secrets
Public customer API	Per-customer API keys with scopes and quotas	Attribution, rotation, and rate limits

JWT is a token format, not a complete authentication strategy. OAuth is an authorization framework. API keys are credentials. Comparing them as interchangeable products causes weak designs.

Start with actors and trust boundaries

Write down every actor before choosing a mechanism:

• end user;
• browser or mobile client;
• application backend;
• background worker;
• autonomous agent;
• MCP server;
• model provider;
• database or vector store;
• administrator.

For each connection, document the identity, credential location, allowed actions, lifetime, rotation method, revocation path, and audit record.

API keys: appropriate for bounded machine access

API keys work well when one server needs to identify itself to another service. Keep provider keys on the server; never ship them in browser JavaScript or mobile binaries.

curl https://api.example.ai/v1/responses \
  -H "Authorization: Bearer $MODEL_PROVIDER_KEY" \
  -H "Content-Type: application/json"

Production key handling needs more than an environment variable:

• separate development, staging, and production keys;
• separate keys by service where the provider supports it;
• restrict permissions and budgets;
• rotate without downtime;
• redact headers and query strings from logs;
• alert on unusual geography, volume, or spend.

See AI Security & Credentials and managing AI API keys.

OAuth: delegated access for users and agents

Use OAuth when an application or agent needs permission to act against a user’s account on another service. The user should see what is requested, grant limited scopes, and be able to revoke access.

OAuth is especially relevant to MCP and agents because a broad token can turn prompt injection into a high-impact action. Prefer:

• narrow scopes;
• short-lived access tokens;
• secure refresh-token storage;
• explicit confirmation for destructive actions;
• server-side token exchange;
• revocation and audit events.

Read OAuth for AI agents and MCP servers and the MCP authentication guide.

JWT: signed claims with operational trade-offs

A JWT can carry an identity, audience, expiry, and scopes. A receiving service can validate the signature without querying a session database on every request.

That is useful across services, but it creates responsibilities:

• validate issuer, audience, signature algorithm, and expiry;
• keep lifetimes short;
• define key rotation;
• do not put secrets or sensitive prompts in the payload;
• handle revocation when immediate logout matters;
• reject tokens intended for another service.

If your application is small, an opaque server-side session can be simpler and safer than inventing a distributed JWT architecture.

Agent identity is not user identity

An agent acting for Jo is not identical to Jo. Record both:

• the user or service that initiated the run;
• the agent identity;
• the tools and scopes granted;
• the policy version;
• every consequential action.

This makes it possible to distinguish “the user deleted the record” from “an agent acting within an approved run deleted the record.” High-impact actions should support confirmation, limits, or human approval.

Recommended reference architecture

1. A user authenticates through a secure session or identity provider.
2. Your backend authorizes the requested agent run.
3. The worker receives a short-lived job identity—not the user’s session cookie.
4. Provider keys come from a production secret store.
5. Third-party access uses user-specific OAuth grants with narrow scopes.
6. The gateway enforces quotas, tool policy, and audit logging.
7. Credentials can be revoked without redeploying the application.

Connect this design to the AI application architecture hub and build an AI gateway.

Common mistakes

• Exposing a provider key in frontend code.
• Giving every worker the same unrestricted production secret.
• Treating possession of a JWT as permission for every action.
• Requesting broad OAuth scopes “for later.”
• Logging authorization headers or full tool arguments.
• Letting an agent reuse an owner’s permanent credential.
• Building rotation without testing whether both old and new keys can overlap safely.

Decision rule

Use API keys for narrow server-to-service access, OAuth for delegated user access, sessions for ordinary user authentication, and short-lived workload identities between production services. Use JWT only when its signed, portable claims solve a real architectural requirement.

The goal is not to select one mechanism for the entire product. It is to give every human, service, and agent the smallest revocable identity needed for its job.