Skip to main content
FrontMCP supports two approaches for integrating external identity providers:

Transparent Mode

Pass-through tokens from the IdP. FrontMCP validates but doesn’t issue tokens.Best for: Single IdP, existing auth infrastructure

Orchestrated Remote

FrontMCP acts as OAuth server, proxying user authentication to upstream IdP.Best for: Multi-provider, progressive auth, federated scenarios

Transparent Mode

Direct token pass-through from external identity provider.

Configuration Options

Provider Examples

Token Flow


Orchestrated Remote Mode

FrontMCP acts as an OAuth server while proxying user authentication to a single mandatory upstream IdP.
In mode: 'remote', GET /oauth/authorize redirects straight to the upstream IdP — FrontMCP never shows its own login page or a provider-selection page. After the IdP returns to /oauth/provider/{id}/callback, FrontMCP exchanges the code, stores the upstream tokens (encrypted, server-side), derives the session identity (sub/email/name) from the upstream user, and mints its own HS256-signed session token. Tools read the upstream token with this.orchestration.getToken('<provider-id>') — the provider id is taken from providerConfig.id (or derived from the provider hostname).

Configuration Options

When to Use Orchestrated Remote

Multiple identity providers - Federate users from different IdPs under one session
Progressive authorization - Users authorize apps incrementally
Custom token claims - Add claims not available from upstream
Consent UI - Let users select which tools/resources to grant

Token Flow


Dynamic Client Registration

Not yet wired. providerConfig.dcrEnabled / providerConfig.registrationEndpoint are accepted by the schema but FrontMCP does not yet perform upstream Dynamic Client Registration. In mode: 'remote' you must provide a pre-registered clientId (and clientSecret for confidential clients) — without a clientId the upstream provider is not registered and /oauth/authorize returns a configuration error. DCR support is planned; track it before relying on it.

Endpoint Overrides

Override auto-discovered endpoints for non-standard IdPs:

Inline JWKS

For offline verification or non-discoverable providers:

Multi-Provider Setup

Combine multiple providers with orchestrated mode:

Per-App Remote Auth

Configure different providers per app:
Use standalone: true to expose an app’s OAuth endpoints directly, bypassing the parent auth.

Troubleshooting

  • Check expectedAudience matches the token’s aud claim
  • Verify JWKS endpoint is accessible
  • Ensure token hasn’t expired
  • Verify IdP URL is correct
  • Check network connectivity
  • Try providing inline JWKS via providerConfig.jwks
  • Register exact redirect URI with IdP
  • Check for trailing slashes
  • Ensure protocol (http/https) matches

Next Steps

Remote Proxy

Handle IdPs without DCR support

Progressive Authorization

Implement incremental app authorization

Local OAuth

Built-in OAuth server setup

Production Checklist

Security requirements for deployment