When to Use OAuth Proxy
Use Proxy When
- IdP doesn’t support DCR
- Need custom token claims
- Want unified auth endpoints
- Require consent UI layer
Use Direct When
- IdP supports DCR (Auth0, Okta)
- Simple pass-through needed
- No custom claims required
- Direct transparent mode works
How It Works
The proxy maintains:- Client registration with pre-provisioned credentials
- JWKS for signing FrontMCP tokens
- Session state linking upstream tokens to local sessions
- Token vault storing upstream tokens for API calls
Configuration
Basic Setup
Configuration Options
| Option | Type | Default | Description |
|---|---|---|---|
remote.provider | string | Required | Upstream IdP base URL |
remote.clientId | string | Required | Pre-registered client ID |
remote.clientSecret | string | - | Client secret (confidential clients) |
remote.scopes | string[] | ['openid'] | Scopes to request from IdP |
consent | ConsentConfig | { enabled: false } | Consent UI configuration |
sessionMode | 'stateful' | 'stateless' | 'stateful' | Session strategy |
Endpoint Overrides
For non-standard IdPs, override auto-discovered endpoints:Inline JWKS
For IdPs without a JWKS endpoint:Token Management
Upstream Token Storage
The proxy stores upstream IdP tokens in the token vault:Automatic Refresh
When upstream tokens expire, the proxy handles refresh:Custom Claims
Add claims from upstream user info to FrontMCP tokens:Multi-Provider Proxy
Proxy multiple IdPs under one FrontMCP instance:Each app maintains its own upstream token in the vault. Users authenticate once per app via progressive authorization.
Proxy vs Direct Comparison
| Aspect | OAuth Proxy | Direct (Transparent) |
|---|---|---|
| Token Issuer | FrontMCP | Upstream IdP |
| JWKS | FrontMCP-managed | IdP-managed |
| Session Control | Full | Pass-through |
| Custom Claims | Yes | No |
| Consent UI | Optional | No |
| DCR Required | No | Yes (or pre-registered) |
| Complexity | Higher | Lower |
Security Considerations
Validate redirect URIs - Ensure callback URLs are registered with the upstream IdP
Use HTTPS - All communication with upstream IdP must be encrypted
Rotate secrets - Periodically rotate client secrets
Monitor token usage - Log and alert on unusual token patterns
Troubleshooting
Callback fails with state mismatch
Callback fails with state mismatch
- Ensure session storage is configured (Redis for multi-instance)
- Check that pending authorization TTL hasn’t expired
- Verify the state parameter is being preserved
Upstream token exchange fails
Upstream token exchange fails
- Verify client credentials are correct
- Check that redirect URI matches exactly (including trailing slash)
- Ensure scopes requested are allowed by IdP configuration
User info not available
User info not available
- Confirm
openidandprofilescopes are requested - Check userinfo endpoint is accessible
- Verify IdP returns expected claims
Refresh token not working
Refresh token not working
- Some IdPs require
offline_accessscope for refresh tokens - Check if IdP rotates refresh tokens (handle rotation)
- Verify refresh token hasn’t been revoked

