// auth_decision_guide

OAuth vs API Keys vs JWT for AI Applications

AI applications usually need more than one auth pattern. The real design question is where human consent ends, where machine identity begins, and how scoped internal access is enforced across agents and tools.

Back to topics

// quick_comparison

Three mechanisms, three jobs

Picking the wrong one usually creates either security debt or needless complexity.

OAuth

best for: Human sign-in, delegated access, consent, and third-party integrations.
strengths: Strong identity model, revocable consent, ecosystem support, and good fit for user-facing AI apps.
watch out for: Heavier implementation and token exchange complexity if you only need simple service auth.

API Keys

best for: Simple server-to-server access, low-friction prototypes, and provider-issued credentials.
strengths: Fast to ship, easy to rotate, and common for external AI model providers and webhooks.
watch out for: Weak identity semantics, easy over-permissioning, and poor auditability when shared across systems.

JWT

best for: Scoped internal APIs, stateless auth, multi-service AI platforms, and agent tool access.
strengths: Carries claims, tenant, scopes, and expiry; works well for short-lived delegated access.
watch out for: Unsafe if long-lived, over-scoped, or trusted without signature, issuer, and audience validation.

// boundary_map

One request, three mechanisms, four boundaries

The mistake is treating this as one auth choice. Follow a request: OAuth authenticates the person at the edge, a scoped JWT carries identity between your services, a policy gate guards irreversible writes — and API keys only ever leave your backend to call third parties.

human

Browser / user

A person or external business user.

OAuth 2.0

edge

Your app & API

Session, token exchange, gateway.

scoped JWT

internal

Internal services

Tools, workers, and AI services.

policy + approval

risk

Risky writes

Payments, refunds, notifications.

policy gate

outbound from the edgeAPI key · server-side External model providers & vendor APIs

Each boundary gets the mechanism that fits it — OAuth for people, JWT between your own services, a policy gate before irreversible writes, and API keys only for outbound calls to third parties.

// applied_patterns

Which pattern, which system

Chat product with signed-in users

OAuth → session → JWT for internal tools

The user must consent, but the AI layer still needs narrow stateless tokens for search, profile, and workspace APIs.

reference doc →

External model provider call

Server-side API key

The provider only needs machine authentication. Do not expose the key to browsers or bundle it with client apps.

reference doc →

Live event-processing agent

Service account → short-lived JWT

An async worker handling queues or notifications needs verifiable machine identity, expiry, and action scopes.

reference doc →

B2B AI SaaS tenant console

OAuth + JWT + policy engine

Tenant admins sign in with OAuth, while downstream services rely on JWT claims and policy checks for isolation.

reference doc →

Decision rules

Use OAuth when a person or external app must grant consent to an AI system.

Use API keys for narrowly scoped machine credentials that do not represent a signed-in user.

Use JWTs between internal services when you need stateless identity, claims, and short-lived scopes.

Combine them when needed: OAuth for login, JWT for internal calls, API keys for provider integrations.

Avoid these anti-patterns

Using one shared API key for every agent, environment, and tenant.

Letting long-lived JWTs execute refunds, purchases, or notifications without approval checks.

Treating OAuth access tokens as a universal internal service credential instead of exchanging or reissuing scoped tokens.

Skipping issuer, audience, and expiry validation on internal JWTs because the service is “private.”

// recommended_patterns

Recommended patterns for AI systems

Most production AI stacks mix these mechanisms — the best architecture chooses each one for a narrow boundary.

Customer-facing AI copilot

OAuth + JWT

Authenticate the user with OAuth, then issue short-lived JWTs so the copilot can call internal tools with the user context and allowed scopes.

Background agent worker

Service account + JWT

Avoid borrowing end-user credentials. Give the worker a machine identity and signed JWTs with narrow write permissions and strict expiry.

Calling external model providers

API keys

Most providers use API keys. Keep them server-side, rotate regularly, and do not reuse the same key across unrelated AI workloads.

Multi-tenant AI SaaS platform

OAuth + JWT + policy layer

OAuth identifies the tenant user, JWT carries tenant claims and scopes, and a policy layer enforces model, data, and tool boundaries.

See the full agent authentication reference flow·Wire tools with a live MCP demo