OIDC in ContextForge is mostly for administering the MCP platform

[chunlongliang-ibm]

We are evaluating ContextForge as MCP gateway, and I am trying to understand how authentication is handled in ContextForge. I am reading https://github.com/IBM/mcp-context-forge/blob/main/docs/docs/manage/sso.md for some guideline, but I got lost after reading this document.

There are three kind of authentications in terms of use case

use case 1: administering the MCP platform.
Gateway administration
MCP server registration
Tool registration
Team management
Governance administration
Audit investigation
Developer portal access

use case 2: Runtime Agent Authentication

use case 3: Delegated User Access

Browser based OIDC SSO belongs to use case 1. However, browser based OIDC SSO in general is not a good fit in use case 2, and use case 3.

I am reading this document, https://github.com/IBM/mcp-context-forge/blob/main/docs/docs/manage/sso.md, which seems mixing three use cases. Reading this doc, I am wondering is ContextForge an MCP Gateway or an Identity Platform?

I would argue that browser based OIDC in ContextForge is mostly for administering the MCP platform, is not for runtime authentication or delegated user access. In runtime, ContextForge is between agent and MCP services, in general it is not easy to for ContextForge to initiate browser SSO. Runtime delegated authorization is usually better handled by the agent layer or a dedicated identity service rather than the MCP gateway itself. With that separation, browser OIDC SSO in ContextForge becomes a platform administration feature, not a core MCP runtime feature. That's a much cleaner story and easier for architects and adopters to understand.

For this particular doc, it would be nice if it starts with something like "For most deployments, SSO is only required for administrators, developers, and operators accessing the ContextForge UI."

The SSO doc appears to set up OIDC as a unified auth layer for both the admin UI and inbound MCP requests, has at least following problems:

Bearer tokens from a browser OIDC flow have short lifetimes — an agent would need to constantly refresh, which assumes it has a refresh token and a client secret, at which point you've just reinvented client credentials flow with extra steps.

The OIDC redirect flow is meaningless for a headless client — an AI agent can't follow a 302 → IdP login page → callback sequence.

It couples gateway availability to IdP availability — if the IdP is unreachable, runtime tool calls fail, even though the gateway itself is up and the credentials are valid.

Audit/attribution becomes muddier — an admin session token vs. a runtime service token should have different scopes, different audit trails, and different revocation paths.

[chunlongliang-ibm]

I just asked Bob to review my concern, here is what Bob said:

The Architectural Distinction
Administrative access (human → UI):

A human opens a browser to configure the gateway, manage tools, view dashboards
OIDC/SSO with browser redirects is the right fit here — it's designed for interactive, human-driven flows
Session cookies, refresh tokens, and IdP-managed MFA all make sense
Runtime access (agent/client → gateway):

An MCP client, AI agent, or service calls the gateway programmatically to invoke tools
There is no browser, no human in the loop, no redirect possible
The correct patterns here are API keys, service tokens (OAuth client credentials), or mTLS — not browser SSO

[chunlongliang-ibm]

Bob agree with me:
An MCP client, AI agent, or service calls the gateway programmatically to invoke tools
There is no browser, no human in the loop, no redirect possible