[FEATURE][AUTH]: Support external OIDC bearer tokens on API and MCP endpoints #3567
Description
📓 Additional Context
A client has been working with ContextForge MCP Hub and has successfully configured Keycloak as an SSO identity provider. They report that the browser-based SSO login flow works excellently — OIDC tokens are validated via JWKS, users are auto-provisioned, and realm roles are correctly mapped to ContextForge RBAC roles.
However, the client has encountered a limitation when attempting to extend this trust relationship to programmatic API access.
Use Case:
The client has AI agents (MCP clients) that need to authenticate against the MCP Hub endpoints (/mcp/, /tools, etc.) using machine-to-machine credentials. Their approach is to have these agents obtain an access token from the same OIDC identity provider that ContextForge already trusts for SSO (via the OAuth2 client_credentials grant) and present that token as a Bearer token on API requests.
Observed Behavior:
When an MCP client sends a Bearer token issued by the configured SSO IdP (Keycloak, but applicable to OAM, PING, etc.), the API authentication layer rejects it. It appears that the API/MCP endpoint authentication only validates internally-minted JWTs (signed with JWT_SECRET_KEY), rather than also accepting tokens from the trusted external IdP and validating them via the JWKS endpoint — even though the SSO flow already has the full OIDC/JWKS validation logic in place.
In other words, the trust relationship with the external IdP seems to be scoped exclusively to the browser-based SSO flow and does not extend to Bearer token authentication on API endpoints.
Expected Behavior:
Since ContextForge has a configured and verified trust relationship with the external IdP (JWKS URI, issuer validation, role mappings, etc.), the client expected that tokens issued by that same IdP would also be accepted as valid Bearer tokens on API and MCP endpoints — with the same role mapping and RBAC enforcement applied. This would enable a unified authentication model where both human users and service accounts authenticate through the same corporate identity provider.
Client Questions:
Is this a known limitation, or is there a missing configuration option that enables external OIDC token validation on API endpoints?
If this is not currently supported, is there a recommended approach for authenticating MCP clients/agents through a corporate OIDC provider without requiring them to have knowledge of ContextForge's internal JWT signing key?
Is support for external IdP bearer tokens on API endpoints on the roadmap?
This capability is described as vital for enterprise deployments where centralized identity management is a requirement for both human users and AI agents/service integrations.