Help with OAuth Setup for Virtual Servers (Claude Web Oauth Client)

[gd-dervaric]

Hello,

I was asked to evaluate the usage of context forge for our company. I managed to get some setup running on Google Cloud. I am currently using Google SSO which works fine for Admin UI access. Using JWT tokens with external clients to connect to configured MCP servers via the virtual servers works also fine.

Now I was asked to make it possible to use Claude Web where you can only configure OAuth for the connectors and I just cannot get it working. Maybe there is some misunderstanding on my side where and how to do it.

In the Virtual Server config screen I can enable OAuth which I understood is for the "client -> context forge" authentication, correct?

I tried Google SSO with:

• Authorization Server URL: https://accounts.google.com
• Scopes: openid email profile

-> in claude web -> I get to the google consent screen of my oauth client app and can login but then I come back with an error

• the context forge log says:
  • "✗ Auth context extraction failed (continuing as anonymous): 401: Invalid token"
  • "Bearer token is not a decodable JWT; deferring to internal verify_credentials"

I tried with a dexidp setup (that uses Google SSO internally):

• Authorization Server URL: https://mydex.....run.app

-> in claude web -> I get the whole flow: Google Consent Screen -> Login -> Dex Grant Access and come back with an error to claude web

• in the context forge log I can see:
  • "Rejecting OIDC ID token masquerading as OAuth access token (issuer=https://dex....run.app, claims=['at_hash'])"
• So it seems it was rejected because it is an ID token?

I also did the oauth flows manually for both use-cases via curl from beginning to end and it works until I get the access tokens back but context forge rejects them then in the end.

Can someone please explain how to get a working setup or where I might have a thinking error? Ideally, with Google SSO, Entra ID or if that does not work with a work-around that allows the browser based SSO? I found much of the current documentation confusing/lacking around this specific topic.

Thanks in advance,
Christian

[rakeshutekar]

Your read of the Virtual Server "enable OAuth" toggle is right — it's the client → ContextForge (resource-server) side, i.e. ContextForge validating the Bearer that Claude Web presents. The failures you're hitting are both the same underlying thing: ContextForge is being handed something that isn't an OAuth 2.0 access token, so it refuses it.

Matching your two logs to the verifier:

Dex — Rejecting OIDC ID token masquerading as OAuth access token (... claims=['at_hash']). This is an explicit, deliberate guard in mcpgateway/utils/verify_credentials.py:

# nonce and at_hash are defined only for ID tokens (OIDC Core §2);
# their presence on a bearer token is a reliable indicator ...
id_token_markers = [claim for claim in ("nonce", "at_hash") if claim in unverified]
if id_token_markers:
    logger.warning("Rejecting OIDC ID token masquerading as OAuth access token ...")
    return None

Dex handed back an ID token (it carries at_hash), and ContextForge rejects any bearer with at_hash/nonce on purpose — an ID token proves who logged in, it is not an API authorization credential, and accepting one would let any client replay its SSO ID token as API access.

Google (accounts.google.com) — Bearer token is not a decodable JWT; deferring to internal verify_credentials → 401: Invalid token. Google's OAuth access tokens are opaque strings, not JWTs, so there's nothing for ContextForge to validate against a JWKS. Google directly is a non-starter as a token issuer for this path for that reason.

So neither upstream is producing the thing ContextForge needs: a JWT access token whose aud matches ContextForge's configured api_audience, signed by a trusted JWKS. The OAuth troubleshooting doc says this directly for the external-IdP-token path — the fix for a rejected token is "confirm aud exactly equals api_audience, and confirm the token type is an access token (not an ID token)."

The cleaner fix: let ContextForge be the authorization server (DCR)

Rather than wiring Claude Web straight at Google/Dex, point Claude Web's connector at ContextForge's own base URL and let it use Dynamic Client Registration. Claude Web (like Claude Desktop) supports the MCP OAuth flow with DCR — it discovers /.well-known/oauth-authorization-server, registers a client automatically, and then ContextForge issues its own access tokens (which are minted as proper OAuth access tokens, so they pass the guard above). ContextForge federates to your Google SSO upstream for the actual human login, so you keep Google as the identity source without ever handing a raw Google/Dex token to the MCP endpoint. See the Dynamic Client Registration guide (docs/docs/manage/dcr.md) — that's the setup that matches "connector where you can only configure OAuth," which is exactly the Claude Web case.

If you must present the upstream IdP token directly

Then it has to be an access token with an audience, not an ID token:

• Dex: request a resource/audience so Dex returns an access token scoped to ContextForge, and set ContextForge's api_audience to exactly that aud. An ID token (with at_hash) will always be rejected regardless of config — that's the guard, not a misconfiguration.
• Entra ID works well here because it issues real JWT access tokens with a configurable aud; register an API/app with an Application ID URI and use that as the audience. This is the sso.md → "Machine-to-machine API auth with external IdP tokens" path referenced in the troubleshooting doc.
• Google direct won't work for the reason above (opaque access tokens) — you'd have to front it with an issuer that mints verifiable JWT access tokens, which is essentially the DCR/ContextForge-as-AS route anyway.

Given your goal (browser-based SSO from Claude Web, Google as the identity source), I'd go with DCR — it's the path designed for exactly this, and it sidesteps the ID-token-vs-access-token problem entirely instead of fighting Dex's token types. If you share whether Claude Web is discovering /.well-known/oauth-authorization-server on your gateway, that'll tell us whether DCR is even being attempted or whether the connector is falling back to treating your configured URL as a plain upstream.