Two credential shapes
Almost every integration is one of two patterns. Both validate an inboundAuthorization: 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 mtls — not oidc.The config blocks at a glance
Rules that apply to every provider
audiencesis required and must match the token’saudclaim. An entry without audiences accepts any audience of that issuer, so keep it explicit.required_scopesmust 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/scopeclaim and Auth0/Entra-stylepermissionsandrolesarrays — so a “role” can be expressed as a scope or as a role claim. - If you omit
jwks_urlandintrospection_url, TrustGate resolves keys via OIDC discovery, which needs theissuerto be a reachablehttps://URL. client_id/client_secreton anoauth2credential are only used for interactive brokering / session mode; pure bearer-token validation needs onlyissuer,audiences,jwks_url, andrequired_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.