---
title: "Verified identity on every call"
description:
  "Authenticate every API, LLM, and MCP call as a verified identity — any
  client, any IdP, any auth method. Managed API keys, JWT from any OIDC
  provider, mTLS, custom TypeScript, and a bundled spec-compliant OAuth server
  for MCP, all validated across 300+ edge locations."
canonicalUrl: "https://zuplo.com/features/authentication"
sourceUrl: "https://zuplo.com/features/authentication"
pageType: "feature"
generatedAt: "2026-08-04"
---

# Every auth method, validated at the edge

> Authenticate every API, LLM, and MCP call as a verified identity — not
> whatever string the caller claims. Any client, any IdP, any auth method:
> managed API keys, JWTs from your existing provider, mTLS, custom TypeScript,
> or the gateway's own spec-compliant OAuth server for MCP — all validated at
> the edge before traffic reaches your origin.

## Auth shouldn't live in 30 different services

Authentication is the most-implemented, most-broken, most-scary code in your
codebase. Centralizing it at the gateway isn't just an aesthetic choice — it's
how you stop shipping the same JWT-validation bug into production every quarter.

- **Auth code in every microservice** — Each backend re-implements JWT
  validation. Each gets it slightly wrong. Each ships its own bug. Multiplied
  across 30 services, you have 30 places to patch when the next CVE drops.
- **API keys stored in a spreadsheet** — The free tier shipped with API keys six
  months ago. The keys live in a Notion page. Rotation is a Slack DM. Revocation
  requires a deploy.
- **Provider lock-in** — Switching from Cognito to Auth0 means a months-long
  migration because validation is bolted into every service. Picking the right
  IdP is a one-way door, and the door is always locked.
- **Auth latency in the data path** — Every request makes a round-trip to a
  centralized auth service before it can do useful work. P99 has three more
  nines than it should. Customers feel the cold-call.

## What you get: consistently enforced authentication across every endpoint

- **One auth surface, every backend** — Validate JWTs, API keys, mTLS certs at
  the edge — once. Backends trust the gateway and skip re-validation. Stop
  reimplementing the same auth logic in every service.
- **Plug in any IdP** — Auth0, Okta, Cognito, Azure AD, Firebase, Supabase,
  Clerk, your own. All you need is a JWKS URL. Switching providers is a config
  change, not a migration project.
- **Self-serve, leak-detected API keys** — Edge-replicated, hashed at rest, with
  a self-serve portal for your customers and GitHub leak detection that catches
  committed keys before attackers do.

## The identity chain: every call has an identity — in, through, and out

Your IdP decides who's calling. Zuplo enforces it — verifying the credential on
the way in, carrying that identity through every policy, and brokering upstream
credentials on the way out so your agents never hold them.

1. **Verify inbound** — Managed API keys, JWTs from any OIDC provider (Auth0,
   Okta, Microsoft Entra ID, Clerk, Cognito, Firebase, Supabase, and more),
   mutual TLS, or custom TypeScript. Or let the gateway issue tokens to MCP
   clients itself. Every credential is validated at the edge and normalized into
   one identity your policies can read.
2. **Enforce through policy** — The verified identity flows into every policy:
   per-user rate limits, per-tool authorization (capability filtering, OpenFGA /
   AuthZEN, or custom TypeScript), metering, and per-subject audit. You can
   govern and bill a verified user — you can't govern a string.
3. **Broker outbound** — The gateway holds the upstream credentials so your
   agents never do: per-user OAuth (encrypted at rest, auto-refresh), shared
   OAuth, and vaulted API keys. Cross-App Access (ID-JAG, an IETF draft)
   exchanges an IdP assertion for a scoped upstream token — Zuplo is a named
   Okta launch partner.

## OAuth server for MCP: a spec-compliant OAuth server, bundled in

MCP clients need an OAuth authorization server to log in — and Zuplo is the only
fully-managed gateway that bundles one. The gateway is its own OAuth 2.1
authorization server for MCP: it registers clients, runs the login, and issues
its own audience-bound tokens, delegating the browser login to your IdP. On
every plan — not an enterprise add-on, not a DIY library.

- OAuth 2.1 authorization server
- Dynamic Client Registration (RFC 7591) + CIMD
- PKCE S256 required
- RFC 8414 authorization-server metadata
- RFC 9728 protected-resource metadata
- RFC 8707 resource indicators — tokens audience-bound per route
- RFC 7009 token revocation
- MCP spec revision 2025-11-25

Browser login is delegated to 11 first-class IdP integrations — Auth0, Okta,
Microsoft Entra ID, Clerk, WorkOS, Amazon Cognito, Google, Keycloak, Logto,
OneLogin, and PingOne — plus any generic OIDC provider. IdP tokens never reach
the MCP client, and a token issued for one route is rejected at another.

See it in context: [MCP Gateway](/mcp-gateway)

## Every auth method, on the same gateway

API keys, JWT (any OIDC provider), Clerk JWT, mutual TLS, basic auth, and custom
TypeScript — all configured per route, all enforced at the edge before traffic
reaches your origin. Compose them per route, chain them across routes, or write
your own.

- API keys (`api-key-inbound`)
- JWT / OAuth 2.0 (any OIDC IdP)
- Clerk JWT (`clerk-jwt-auth-inbound`)
- Mutual TLS (client cert)
- Basic Auth (RFC 7617)
- Custom TypeScript (RBAC / ABAC)

Read the [Authentication Guide](https://zuplo.com/docs/concepts/authentication).

## API key lifecycle: issue, validate, and revoke without writing the auth service

Hashed-at-rest, edge-replicated API keys with a developer portal for self-serve,
a Management API for programmatic issuance, an open-source React component for
embedding into your own dashboard — and GitHub leak detection so a committed key
gets noticed before an attacker exploits it.

- Hashed at rest
- Edge-replicated · ~5ms validation
- Self-serve developer portal
- Custom metadata per key
- Expiration + rotation
- GitHub leak detection

Example: issuing a key through the Management API —

```http
POST /v1/api-keys
Content-Type: application/json

{
  "consumer": "acme",
  "metadata": { "plan": "pro" }
}
```

Validation runs via `api-key-inbound` at the edge: hashed-at-rest keys
replicated to 300+ data centers, validated in single-digit ms with no round-trip
to a central DB (~5ms on a hit, 401 once revoked). GitHub leak-detection scans
catch committed keys before attackers do, and customers can rotate their own
without filing a ticket.

Read the [API Keys deep-dive](/features/api-key-management).

## What makes Zuplo different

Most gateways model auth as a single dropdown per route. Zuplo treats it as
composable code — because real teams have employees, partners, machines, and
migrations all happening at once.

- **Composable methods, not exclusive ones** — Most gateways force you to pick
  one auth method per route. Zuplo lets you chain them — accept either an API
  key OR a Bearer token, fall through to a custom check, and feed all of them
  into the same RBAC policy.
- **Authorization at the gateway, your way** — Write authorization checks as
  TypeScript policies — full access to `request.user`, headers, body, env vars,
  and ZoneCache, with the rejections pinned by the built-in zuplo test runner
  against a real deployment. Or wire in the OpenFGA integration for
  relationship-based access control without operating a rules engine yourself.
  Either way, the decision lands at the gateway, not duplicated across every
  backend service.
- **Validation runs in the gateway, not over the network** — Token validation
  and policy decisions happen inside the gateway runtime across 300+ edge data
  centers — not against a remote auth service. No separate service to scale, no
  round-trip per request, no single point of failure for a system every request
  needs.
- **Per-customer attribution, automatic** — Because Zuplo issues API keys, every
  authenticated request is attributed to its consumer. Logs, analytics, rate
  limits, and monetization all key off identity without instrumentation code in
  your services.

## What teams use this for

**"Our customers want API keys; our employees use SSO."** Stack two policies on
the same route: `api-key-inbound` for partner traffic,
`open-id-jwt-auth-inbound` pointed at your Okta JWKS for employee traffic. The
first method that succeeds populates `request.user`. Done.

**"We're switching from Cognito to Auth0."** Run both for 90 days. Update one
config field — the JWKS URL — when you're ready to cut over. No
service-by-service migration, no client SDK rewrites, no scheduled downtime.

**"We need MFA for admin endpoints only."** Apply your standard auth on every
route, then add a `custom-code-inbound` policy on `/admin/*` that checks for an
MFA claim in `request.user.data`. Reject with `HttpProblems.forbidden()` if it's
missing.

**"A customer just committed their API key to a public repo."** Zuplo's GitHub
leak detector finds it before they do. You get an email; the customer's portal
shows a banner; one click revokes and issues a new one.

## FAQ

**How do I add authentication to an API?** Authenticate at the gateway, not in
every backend service. Put your API behind an API gateway like Zuplo and pick
the methods you want — API keys for B2B partners, JWT/OAuth 2.0 for human users,
OpenID Connect for SSO, mutual TLS for high-security backends, or all of the
above on different routes. The gateway validates the credential at the edge,
hands you a normalized identity, and forwards a trusted request to your backend.

**Does Zuplo support OAuth 2.0, OpenID Connect, JWT, and SSO providers?** Yes.
The OpenID JWT policy validates tokens from any OAuth 2.0 or OIDC provider —
point it at the issuer's JWKS URL and it verifies signatures, audiences, scopes,
and expiry at the edge. First-party guides exist for Auth0, Okta, AWS Cognito,
Azure AD / Entra ID, Firebase, Supabase, and Clerk. Multiple providers on the
same gateway, multiple methods on the same route, no SDK to install.

**How do I do API key authentication?** API keys are the simplest way to
authenticate B2B partners and developers — a long random string the client sends
with every request. Zuplo issues hashed-at-rest, edge-replicated keys (`zpka_`
prefix, GitHub leak-detection partner) that customers self-serve through the
included developer portal. Validation happens in single-digit milliseconds at
the edge; downstream policies see the consumer's metadata for plan, tenant, and
per-key rate limits.

**Can I implement custom RBAC or per-tenant authorization at the gateway?** Yes.
After authentication, your custom TypeScript policy reads the authenticated
identity and enforces whatever access rules you need — role checks,
attribute-based rules, OpenFGA integration, per-tenant gates. The gateway
short-circuits unauthorized requests with a 403, no SDK to install, no second
auth round-trip to your backend. Most teams start with a 30-line policy and grow
it from there.

**How do I support multiple authentication methods on the same API?** Different
consumers often need different auth — partners use API keys, end users use
OAuth, internal teams use mTLS or SSO. With Zuplo, you stack auth methods on the
same route: each one runs in turn, the first that succeeds populates the
identity context, and the request proceeds. This also makes auth migrations safe
— add the new method alongside the old, migrate consumers, retire the old
without downtime.

**Does Zuplo work with Auth0, Okta, Clerk, Entra, or my IdP?** Yes — Zuplo is
IdP-agnostic. Any OAuth 2.0 / OIDC-compliant identity provider works out of the
box, and there are dedicated policies for Auth0, Clerk, Supabase, and other
popular IdPs. For partner workloads, integrate with Entra ID app registrations,
Transmit Security CIAM, AWS Cognito, or Google Identity Platform. You keep your
existing IdP; Zuplo just validates the tokens at the edge.

**What's the best API gateway for authentication?** The right gateway lets you
swap or stack auth methods without rewriting backend code, validates credentials
at the edge for low latency, supports your existing IdP, and gives you a place
to add custom authorization in code. Zuplo ships every common method (API keys,
JWT, OAuth 2.0, OpenID Connect, mTLS, custom TypeScript), runs validation in
300+ POPs, and has dedicated guides for Auth0, Okta, Clerk, Cognito, and Azure
AD.

**How does mTLS authentication work for partner APIs?** Mutual TLS uses client
certificates instead of API keys or tokens — the client and gateway both prove
their identity during the TLS handshake. Banks and regulated partners often
require it. Zuplo terminates mTLS at the edge, validates the client certificate
against your CA, and exposes the certificate's subject info to downstream
policies for fine-grained authorization. Available on Enterprise; talk to a
security expert to wire it up.

## Next steps

- Start a free account: https://portal.zuplo.com/signup
- Read the
  [Authentication Guide](https://zuplo.com/docs/concepts/authentication)
- Read the [API Keys deep-dive](/features/api-key-management)
- See it on the [MCP Gateway](/mcp-gateway)
- Talk to a Security Expert: [/schedule-call](/schedule-call)