Multi-client authentication

Stop one compromised client credential from affecting every other client that shares your gateway.

As you onboard more clients, partners, and applications, a shared credential becomes a liability. One leaked key gives you no way to tell which caller caused an incident, and rotating it disrupts every integration at once. Each caller needs its own identity and access to only what it is entitled to reach.

What you can do

  • Issue a separate API key per client so that revoking or rotating one key leaves every other client working.
  • Verify inbound JWTs against a trusted issuer so that callers from your own identity provider are accepted without sharing a static secret.
  • Combine authentication methods on one surface (API key, JWT bearer, mTLS, or DID auth) so that different client types reach the same service under one configuration.
  • Evaluate each request against route-level rules so that an authenticated client only reaches the routes it is authorised for.
  • Restrict individual MCP tools per client so that privileged tools stay available only to the clients you choose.

How it works

Client AAPI keyClient BJWTClient CmTLSown credentialAgent GatewayAccess Point · Caller Contextauthenticates: api_key · jwt_bearer ·api_key_provider · mtls · did_authsource_authOPA policygateway + surface scope · MCP per-toolreads input.source_auth.method✕ 403 Forbidden · method = failedallow → forwardManaged agentor routed service

Authentication is attached to a surface’s access point as a Caller Context, not built into the calling client. Each access point declares one or more source-auth methods: api_key, api_key_provider, jwt_bearer, mtls, or did_auth. API keys are validated either against a secret in the secrets store or against the API Key Provider, which holds a separate, independently revocable key for each client. JWT bearer auth checks the token against a verification strategy that pins the trusted issuer and its signing keys.

Once a caller is authenticated, the outcome is passed to the OPA policy layer as input.source_auth: its method plus the authenticated detail, such as the API key’s name or the JWT claims. Policies are evaluated at gateway scope (applied across the appliance) and surface scope (specific to one access point), and MCP surfaces can bind individual tools to their own policies. Each client therefore reaches only the routes and tools its identity permits.

A request whose credential is missing or invalid is not blocked at the access point; it is recorded as source_auth.method == "failed" and passed to the policy layer. A surface or gateway policy that requires a valid method then denies it with 403 Forbidden before the request reaches the target, so keep such a policy in place.