This guide is for developers building their own AI agents that connect to MCP Gateway directly using the MCP SDK (streamable-http transport). If you’re using TrueFoundry’s Agent API, authentication is handled automatically.
Overview
The approach for on-behalf-of authentication depends on two factors:- MCP Server Auth Type: No Auth, Header Auth, OAuth2, or Token Passthrough
- End User Type: TrueFoundry platform user or non-TrueFoundry user
| MCP Auth Type | End User Type | Approach |
|---|---|---|
| No Auth | Any | Virtual Account token |
| Header Auth | Any | Virtual Account token |
| OAuth2 | TrueFoundry user | User’s TF token + OAuth flow |
| OAuth2 | Non-TrueFoundry user | External Identity + OAuth flow |
| Token Passthrough | Any | External Identity + user’s JWT |
Understanding MCP Auth Types
When registering an MCP server, you choose an authentication type that determines how requests are authenticated with the upstream MCP server.Terminology: In this guide, “you” refers to the developer building an AI agent using TrueFoundry. “Your end users” refers to the people who use your AI agent (your customers).
No Auth
The MCP server doesn’t require any authentication. Use for public APIs or demo servers.Header Auth (Static Headers)
The MCP server requires a static API key or token that is the same for all requests. You configure this credential once, and TrueFoundry injects it into every request regardless of which end user is calling. Example: An MCP server that uses a shared API key.OAuth2
The MCP server requires end-user-specific OAuth tokens to access external services like GitHub, Slack, or Atlassian. Each end user must complete an OAuth consent flow to grant your agent access to their resources on those services. Use OAuth2 when:- The MCP server connects to third-party services (GitHub, Slack, Atlassian, Google, etc.)
- End users need to access their own accounts on those services (their GitHub repos, their Slack channels)
- You want TrueFoundry to manage OAuth token storage and refresh
- End user authenticates with your system (TrueFoundry account or via External Identity)
- End user calls your agent → MCP Gateway returns auth error with authorization URL
- End user visits URL and completes OAuth consent on the third-party service (e.g., GitHub)
- TrueFoundry stores the OAuth token for that end user
- Future requests automatically include the end user’s OAuth token
Token Passthrough
The MCP server expects to receive a JWT that you issue to your end users. TrueFoundry passes this JWT directly to the MCP server without any transformation. Use Token Passthrough when:- You have your own IdP (e.g., Auth0, Okta, Cognito) that authenticates your end users
- The MCP server is configured to validate JWTs from your IdP
- You want to control authentication entirely through your own system
- Your end user authenticates with your IdP and receives a JWT
- End user calls your agent with their JWT
- TrueFoundry passes the JWT directly to the MCP server
- The MCP server validates the JWT against your IdP’s configuration
OAuth2 vs Token Passthrough: Which to Choose?
| Question | If Yes → |
|---|---|
| Does the MCP server connect to third-party services (GitHub, Slack, etc.)? | OAuth2 |
| Does the MCP server validate tokens from your IdP? | Token Passthrough |
1. Virtual Account
Use when: MCP server has No Auth or Header Auth, and you want a shared token for all your end users. Virtual Accounts allow you to create a service account with specific permissions to access MCP servers. Your application uses the Virtual Account token to authenticate all requests, regardless of which end user is making the request.1
Create a Virtual Account
- Navigate to Settings > Virtual Accounts in the TrueFoundry UI
- Click Create Virtual Account
- Give it a descriptive name (e.g.,
my-agent-mcp-access) - Add permissions for the MCP servers your agent needs to access
2
Generate a token
After creating the Virtual Account, generate a token. This token will be used by your application to authenticate with MCP Gateway.
3
Use the token in your agent
Handling OAuth Flows
When connecting to an OAuth2-protected MCP server, if the user hasn’t completed OAuth consent, the MCP Gateway returns an error containing the authorization URL. Your agent needs to extract this URL and redirect the user.2. OAuth2 for TrueFoundry Users
Use when: MCP server uses OAuth2 authentication, and your end users are TrueFoundry platform users. When your end users have TrueFoundry accounts, they can use their Personal Access Token (PAT) to authenticate. The MCP Gateway manages OAuth2 tokens for each user automatically.1
User generates their PAT
Each end user generates their own Personal Access Token from TrueFoundry:
- Navigate to Settings > API Keys
- Generate a new API key
- Provide this token to your application
2
Call MCP Gateway with user's PAT
Use the user’s PAT as the
auth_token in the call_mcp_with_oauth function shown in Handling OAuth Flows.If the user hasn’t completed OAuth consent for this MCP server, you’ll get back auth_required: True with the authorization URL. Redirect them to complete OAuth, then retry.3. OAuth2 for Non-TrueFoundry Users
Use when: MCP server uses OAuth2 authentication, and your end users are NOT TrueFoundry platform users (e.g., your own customers in a B2B scenario). In this scenario:- You have your own platform with your own IdP (e.g., Auth0, Okta, Cognito)
- Your end users login to your platform and get a JWT
- You pass that JWT to the MCP Gateway
- TrueFoundry validates the JWT and allows access to MCP servers
1
Configure SSO Integration
Register your IdP with TrueFoundry:
- Navigate to Settings > SSO
- Create a new SSO configuration pointing to your IdP
- Important: Set login enabled to
false(this SSO is only for external identity, not platform login) - Note the SSO FQN for the next step
2
Create External Identity
Create an External Identity that maps JWTs from your IdP to TrueFoundry access:
- Navigate to Access > External Identities
- Click Add External Identity
- Select the SSO FQN from step 1
- Optionally add claims to match specific users/tenants
For detailed instructions, see Setup External Identity.
3
Grant MCP server access
Add the External Identity as a collaborator on the MCP server:
- Navigate to the MCP server’s settings
- Go to Collaborators
- Add the External Identity with appropriate permissions
4
Call MCP Gateway with end user's JWT
When your end user logs into your platform, your application receives their JWT. Use that JWT as the
auth_token in the call_mcp_with_oauth function shown in Handling OAuth Flows.If the user hasn’t completed OAuth consent for this MCP server, you’ll get back auth_required: True with the authorization URL. Redirect them to complete OAuth, then retry.After completing OAuth, the token is stored and associated with their External Identity.4. Token Passthrough
Use when: MCP server uses Token Passthrough authentication, where the user’s JWT is passed directly to the MCP server. Token Passthrough is used when the MCP server itself validates the user’s token (rather than relying on OAuth2 token exchange). This requires an External Identity setup.1
Set up External Identity
Follow steps 1-3 from OAuth2 for Non-TrueFoundry Users to create an External Identity for your users.
2
User obtains JWT from OAuth provider
Your end user authenticates with the OAuth provider that the MCP server expects and obtains a JWT token.
3
Pass the token through
The user’s JWT is automatically passed through to the MCP server:
With Token Passthrough, the MCP server validates the token directly. Make sure the JWT is valid and has the required claims/scopes for the MCP server.