Skip to main content
An auth credential is how a client proves it may act as a consumer. Credentials are created at the gateway level and attached to one or more consumers, so you can rotate or share them independently of the consumer itself. This is distinct from a registry’s target auth, which is how TrustGate authenticates to the upstream provider.

​
Auth types

typeHow the client authenticatesRouting mode
api_keyX-AG-API-Key: ag_… headerinline
oauth2Authorization: Bearer <jwt> validated against an OAuth2 providerinline
idpAuthorization: Bearer <jwt> from your IDP; claims select a rolerole_based
mtlsClient certificateinline

​
API keys

API keys are prefixed ag_. The raw secret is returned once, at creation — store it then. TrustGate only persists a SHA-256 hash; at request time it hashes the inbound key and compares, so the secret is never recoverable from the gateway. 
# create → returns api_key (cleartext) once
POST /v1/gateways/{gateway_id}/auths
{ "name": "my-app-key", "type": "api_key" }

# attach to a consumer
POST /v1/gateways/{gateway_id}/consumers/{id}/auths/{auth_id}

​
OAuth2 / IDP / mTLS

JWT- and certificate-based credentials carry a config block:
TypeConfig fields
oauth2issuer, audiences, jwks_url, introspection_url, client_id/secret, required_scopes, allowed_algorithms.
idpissuer, audiences, jwks_url, public_keys, required_scopes, allowed_algorithms, subject_claim.
mtlsca_cert, allowed_common_names, allowed_dns_names, allowed_fingerprints.
For idp credentials, the validated token’s claims are matched against role IDP mappings to select the consumer’s routing — this is how identity-based routing works.

​
Managing auth

CRUD lives under /v1/gateways/{gateway_id}/auths; attach/detach via the consumer’s …/auths/{auth_id} sub-resource. See the Auth API. Next: govern traffic with policies.