Skip to main content
This section is the practical, provider-by-provider companion to Auth, Consumers, and Roles. Those pages define the concepts; the pages here are step-by-step manuals for standing up a real identity provider and pasting the exact credential payloads TrustGate expects.

Two credential shapes

Almost every integration is one of two patterns. Both validate an inbound Authorization: Bearer <jwt> against your IdP’s JWKS.
A role_based consumer carries exactly one identity credential (oauth2 or oidc). MCP consumers accept api_key, oauth2, and mtlsnot oidc.

The config blocks at a glance

Rules that apply to every provider

  • audiences is required and must match the token’s aud claim. An entry without audiences accepts any audience of that issuer, so keep it explicit.
  • required_scopes must not contain OIDC protocol scopes (openid, profile, email) — those are not carried by access tokens and TrustGate rejects them.
  • Scope matching checks the token’s scp/scope claim and Auth0/Entra-style permissions and roles arrays — so a “role” can be expressed as a scope or as a role claim.
  • If you omit jwks_url and introspection_url, TrustGate resolves keys via OIDC discovery, which needs the issuer to be a reachable https:// URL.
  • client_id / client_secret on an oauth2 credential are only used for interactive brokering / session mode; pure bearer-token validation needs only issuer, audiences, jwks_url, and required_scopes.

Provider manuals

Okta

Custom authorization server, scopes, groups claim, and both credential shapes.

Entra ID

App registration, exposed API scopes, app roles, and both credential shapes.