---
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-10-08"
---

# 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. You haven't slept well since.
- **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.

## 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.

## 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.

## 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 on the 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) (`open-id-jwt-auth-inbound`)
- Clerk JWT (`clerk-jwt-auth-inbound`)
- Mutual TLS (client cert)
- Basic Auth (RFC 7617)
- Custom TypeScript (RBAC / ABAC) (`custom-code-inbound`)

6+ methods, composable. No SDK — all edge policies. Custom RBAC in TypeScript.

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

## 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.

- **Issue — self-serve developer portal.** Customers log in, create keys, attach metadata, and get the documentation in one flow. Branded to your domain.

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

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

- **Validate — `api-key-inbound` at the edge.** Hashed-at-rest keys replicated to 300+ data centers. Validation in single-digit ms — no round-trip to a central DB. (Hit: ~5ms; revoked: 401.)
- **Revoke — leak detection + one-click rotate.** GitHub scan catches committed keys before attackers do. Customers can roll their own without filing a ticket.

Also: hashed at rest, edge-replicated (~5ms validation), self-serve developer portal, custom metadata per key, expiration + rotation, GitHub leak detection.

- [Read the API Keys deep-dive](/features/api-key-management)
- [View API key lifecycle docs](https://zuplo.com/docs/articles/api-key-management)

## Auth that fits how teams actually ship

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. Customers love it the way you'd expect them to love an alert that prevented a breach.

## Frequently Asked Questions

### 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

Spin up a free Zuplo project, drop in any auth method, and consolidate the most-broken code in your stack.

- [Start for free](https://portal.zuplo.com/signup)
- [Talk to a security expert](/schedule-call)
- [Read the docs](https://zuplo.com/docs/concepts/authentication)