Skip to main content
This section is the practical, provider-by-provider companion to Auth, Consumers, and Roles. Those pages define the concepts; the manuals here walk through standing up a real identity provider and configuring TrustGate in the NeuralTrust app (Agent Gateway → Identity and Consumers).

​
Two patterns

Almost every integration is one of two patterns. Both validate an inbound Authorization: Bearer <jwt> against your IdP’s JWKS. You can use the same Okta or Entra tenant for both — they are two TrustGate auth types, not two different IdPs.

​
How OIDC and OAuth2 relate

In the industry, OIDC is built on OAuth2 (login + identity claims). In TrustGate they are separate Auth types with different jobs: So: same IdP, two auths if you need both patterns — an OIDC auth for LLM identity routing, and an OAuth2 auth for MCP login. MCP cannot use OIDC because agents need the gateway to run the interactive OAuth login.
An Identity-based LLM consumer carries exactly one identity auth (OIDC or OAuth2). LLM consumers can also use API key. MCP consumers use OAuth2 only — not OIDC or API key.

​
Built-in provider (self-hosted only)

On a self-hosted External install the product console can act as the authorization server itself, so MCP consumers work without an external IdP — useful for a proof of concept before you involve Okta or Entra. It is enabled by default there and is not available in Hybrid, where the control plane stays on NeuralTrust SaaS. The built-in provider only ever applies to an MCP consumer that has no OAuth2 auth of its own. As soon as you attach one, that IdP is used exclusively — the built-in provider cannot widen access to a consumer you have deliberately bound to Okta or Entra. The manuals below remain the path for production.

​
Where to configure in the app

​
Rules that apply to every provider

  • Audiences is required and must match the token’s aud claim.
  • Required scopes must not include OIDC protocol scopes (openid, profile, email, offline_access) — TrustGate rejects them.
  • Scope matching checks the token’s scp/scope claim and Auth0/Entra-style permissions and roles arrays — so a permission can be expressed as a scope or as a role claim.
  • For OAuth2 interactive MCP login, choose Setup → Interactive login · IdP with discovery (Okta, Entra ID), leave Session mode disabled, and register {mcp_base_url}/oauth/callback as a redirect URI on the IdP app (Okta: OIDC Web Application, not API Services).
  • JWKS URL can usually stay under Token validation · advanced for discovery IdPs; TrustGate resolves keys from the issuer when needed.

​
Provider manuals

Okta

Custom authorization server, scopes, groups claim, and both app patterns.

Entra ID

App registration, exposed API scopes, app roles, and both app patterns.