Overview

An auth is how a client proves it may act as a consumer. Distinct from a registry’s upstream credential (how TrustGate calls the model provider or MCP server). Two kinds of auth entities exist:

• API keys belong to one consumer. Issue, rotate, and revoke them on the consumer’s General tab under Authentication.
• Trust anchors — external identity providers and mTLS certificate authorities — are gateway-level and shared by many consumers. Manage them at Settings → Agent Gateway → Machine identity, then select one on the consumer under Authentication → Identity provider. Which callers of a shared anchor may enter a given consumer is the consumer’s auth binding.

​

Types

oidc is a deprecated alias of oauth2: type: oidc and config.oidc are still accepted on create and update, but responses always carry the oauth2 shape. mTLS anchors are created with the Admin API (the console form offers IdP (JWT)) and attach to consumers on both planes. See mTLS.

​

API keys

1. Open the consumer → General → Authentication → API key → Add API key (or pick API key when creating the consumer; one key is issued on create).
2. Copy the secret once. Use it in requests or in the consumer Connect snippets.
3. Regenerate or Revoke from the same list.

Keys are prefixed ag_. TrustGate stores a hash; the secret cannot be recovered. Rotate by creating a new key, updating clients, then revoking the old one. Both planes accept the key as X-AG-API-Key, as x-api-key (Anthropic-style clients), or as Authorization: Bearer ag_…. A bearer that starts with ag_ is treated as an API key; any other bearer goes to the OAuth2 validators. An MCP consumer called with an API key runs as principal app:<consumer_id>, so rotating or renaming a key never strands the upstream accounts linked to the application.

​

OAuth2 setup modes

One oauth2 entity covers every IdP pattern; the Setup choice decides which fields you fill. introspection_url validates opaque tokens without session mode. HMAC algorithms (HS*) are rejected: only asymmetric signatures are accepted. When public_keys are set, discovery is skipped.

​

Two ways to use an IdP

The same Okta or Entra tenant can back both. What differs is whether TrustGate only checks a token or also runs the login. When a request carries a bearer JWT, TrustGate picks the provider by the token’s iss and aud among the auths attached to the consumer’s path, so one consumer may attach several IdPs. Client-credentials tokens are for curl checks or M2M apps, never for interactive agents.

​

Rules for every provider

• Audiences is required and must match the token’s aud claim. An api:// resource URI and its bare identifier count as the same audience.
• Required scopes must not include openid, profile, email, or offline_access.
• Scope matching uses scp/scope and Auth0/Entra-style permissions and roles arrays.
• Interactive MCP: Setup → Interactive login · IdP with discovery, Session mode off, Okta app type Web Application (not API Services).
• JWKS URL can stay under Token validation · advanced; TrustGate resolves keys from the issuer when needed.
• Telemetry records trustgate.principal.method as external_jwt (your IdP’s token), oauth (a gateway-brokered login), api_key, mtls, or introspection.

​

Provider manuals