The gateway should support the validation of a token through an external JWKS_URI?

[Homere-AI]

When an MCP client wants to consume a specific MCP virtual serveur though API, the gateway perhaps should be able to verify the signature on an incoming JWT, trust it and verify some claims (AUD, SERVER, etc.). Then a client will be able to generate the JWT on the IDP directly and send it to the GW. It seems that there is a parameter on the GW (SSO_GENERIC_JWKS_URI) but it doesn't seems to sync the keys to validate signature of tokens non generated through the GW.

[Homere-AI]

It seems actually possible by importing manually the certs in the internal public key PATH via JWT_PUBLIC_KEY_PATH

[crivetimihai]

Hi @Homere-AI, good find on JWT_PUBLIC_KEY_PATH — that does work for manual key import.

To clarify the full picture on external JWKS support:

1. SSO_GENERIC_JWKS_URI — This config option does exist and is designed to point to an external OIDC JWKS endpoint for token signature verification. It's used during SSO bootstrap to configure the jwks_uri in the provider config. If tokens signed by the external IdP are presented to the gateway, this setting tells the gateway where to fetch the public keys for verification.

2. JWT_PUBLIC_KEY_PATH — As you discovered, this allows importing the public key directly (e.g., for RS256 asymmetric verification) without needing a JWKS endpoint.

3. Per-server OAuth — When OAuth is enabled on a virtual server, the gateway uses the configured Authorization Server's JWKS endpoint (discovered via .well-known/openid-configuration) to validate tokens for that specific server.

If SSO_GENERIC_JWKS_URI isn't syncing keys as expected, could you share your exact configuration and the error/behavior you're seeing? There may be a caching or refresh timing issue worth investigating.

[Homere-AI]

It seems that it stays stuck to /.well-known/oauth-authorization-server instead of .well-known/openid-configuration :
time": "2026-03-09T14:49:45", "name": "mcpgateway.services.structured_logger", "levelname": "WARNING", "message": "[http_gateway] Request completed: GET /servers/f22575edce394a2aafeed6d1efd44e68/mcp - 401", "component": "http_gateway", "category": null, "user_id": null, "user_email": null, "team_id": null, "duration_ms": 1.6014575958251953, "custom_fields": null, "tags": null, "correlation_id": "log7739951314a478852d5bd88bc6d25", "operation_type": "http_request", "request_method": "GET", "request_path": "/servers/f22575edce394a2aafeed6d1efd44e68/mcp", "response_status_code": 401, "user_agent": "PostmanClient/11.85.0 (AppId=08309c69-329d-4e5f-a8ac-4d654943fbc8)", "client_ip": "172.19.0.1", "metadata": {"event": "request_completed", "response_time_category": "fast"}, "hostname": "44143ca38b05", "process_id": 1, "timestamp": "2026-03-09T14:49:45.887690+00:00", "@timestamp": "2026-03-09T14:49:45.887758Z", "request_id": "log7739951314a478852d5bd88bc6d25"}
{"asctime": "2026-03-09T14:49:45", "name": "uvicorn.access", "levelname": "INFO", "message": "172.19.0.1:56490 - "GET /servers/f22575edce394a2aafeed6d1efd44e68/mcp HTTP/1.1" 401", "@timestamp": "2026-03-09T14:49:45.888564Z", "hostname": "44143ca38b05", "process_id": 1}
{"asctime": "2026-03-09T14:49:46", "name": "mcpgateway.middleware.correlation_id", "levelname": "DEBUG", "message": "Generated new correlation ID: 32fb9aa3e43540bc99b0037f413501f7", "@timestamp": "2026-03-09T14:49:46.059436Z", "hostname": "44143ca38b05", "process_id": 1}
{"asctime": "2026-03-09T14:49:46", "name": "mcpgateway.services.structured_logger", "levelname": "WARNING", "message": "[http_gateway] Request completed: GET /.well-known/oauth-authorization-server - 404", "component": "http_gateway", "category": null, "user_id": null, "user_email": null, "team_id": null, "duration_ms": 8.703947067260742, "custom_fields": null, "tags": null, "correlation_id": "32fb9aa3e43540bc99b0037f413501f7", "operation_type": "http_request", "request_method": "GET", "request_path": "/.well-known/oauth-authorization-server", "response_status_code": 404, "user_agent": "PostmanRuntime/7.51.1", "client_ip": "172.19.0.1", "metadata": {"event": "request_completed", "response_time_category": "fast"}, "hostname": "44143ca38b05", "process_id": 1, "timestamp": "2026-03-09T14:49:46.069967+00:00", "@timestamp": "2026-03-09T14:49:46.070172Z", "request_id": "32fb9aa3e43540bc99b0037f413501f7"}
{"asctime": "2026-03-09T14:49:46", "name": "uvicorn.access", "levelname": "INFO", "message": "172.19.0.1:56496 - "GET /.well-known/oauth-authorization-server HTTP/1.1" 404", "@timestamp": "2026-03-09T14:49:46.071483Z", "hostname": "44143ca38b05", "process_id": 1}

Conf :

SSO_GENERIC_ENABLED=true
SSO_GENERIC_PROVIDER_ID=keycloack
SSO_GENERIC_DISPLAY_NAME=Company SSO
SSO_GENERIC_CLIENT_ID=MCPG_Remote_Introspection
SSO_GENERIC_CLIENT_SECRET=my-test-key
SSO_GENERIC_AUTHORIZATION_URL=https://dns/realms/mcp-gateway-realm/protocol/openid-connect/auth
SSO_GENERIC_TOKEN_URL=https://dns/realms/mcp-gateway-realm/protocol/openid-connect/token
SSO_GENERIC_USERINFO_URL=https://dns/realms/mcp-gateway-realm/protocol/openid-connect/userinfo
SSO_GENERIC_ISSUER=https://dns/realms/mcp-gateway-realm
SSO_GENERIC_JWKS_URI=https://dns/realms/mcp-gateway-realm/protocol/openid-connect/certs

Optional: Auto-create users on first login

SSO_AUTO_CREATE_USERS=true

Optional: Preserve local admin authentication

SSO_PRESERVE_ADMIN_AUTH=true

JWT_AUDIENCE=mcpgateway-api
JWT_AUDIENCE_VERIFICATION=true
JWT_ISSUER_VERIFICATION=true
JWT_ISSUER=https://dns/realms/mcp-gateway-realm
REQUIRE_TOKEN_EXPIRATION=true

[crivetimihai]

Hi @Homere-AI, thanks for the follow-up with the log.

The 401 with /.well-known/oauth-authorization-server in the logs confirms what's happening. Here's the discovery flow in the DCR service:

1. First attempt: RFC 8414 — /.well-known/oauth-authorization-server (inserted between host and path)
2. Fallback: OIDC — /.well-known/openid-configuration

PR #3207 fixed the RFC 8414 well-known URL construction for path-based issuers — the URL was being built incorrectly in some cases. If you're on a version before that fix, the RFC 8414 URL might be malformed, causing discovery to fail without properly falling back to OIDC.

Recommendations:

1. Update to the latest RC2 — it includes the RFC 8414 URL fix from fix(auth): correct RFC 8414 well-known URL construction for path-based issuers #3207.

2. Set the JWKS URI explicitly to bypass discovery entirely. On the virtual server's OAuth configuration, set jwks_uri directly to your IdP's JWKS endpoint. This avoids the discovery chain altogether.

3. If using Keycloak, set SSO_KEYCLOAK_BASE_URL and SSO_KEYCLOAK_REALM — the dedicated Keycloak discovery path goes straight to openid-configuration, bypassing RFC 8414.

Related issues:

• [FEATURE][AUTH]: Support external OIDC bearer tokens on API and MCP endpoints #3567 — Support for External OIDC Bearer Tokens on API/MCP Endpoints (covers the broader use case of trusting external IdP tokens)
• [BUG][AUTH]: OAuth RFC 9728 protected resource metadata not working with Cursor IDE #3535 — RFC 9728 not working with Cursor (related OAuth metadata issue)

Which IdP are you using? If you can share the issuer URL, I can confirm whether the fix in #3207 addresses your specific case.

[Homere-AI]

Hello @crivetimihai,

I have update my local image and process as you mentionned:

• Create a virtual serveur with Oauth enable for MCP client
• Set JWKS URI in conf

I still have a 401 and i don't have a fallback (My IDP is using: /.well-known/openid-configuration):

context-forge | {"asctime": "2026-04-13T09:31:25", "name": "uvicorn.access", "levelname": "INFO", "message": "172.19.0.1:50886 - "GET /servers/19ffb95d4883401583deb84dbacf30ce/mcp HTTP/1.1" 401", "@timestamp": "2026-04-13T09:31:25.864731Z", "hostname": "004a16e755bb", "process_id": 1}
context-forge | {"asctime": "2026-04-13T09:31:26", "name": "mcpgateway.middleware.correlation_id", "levelname": "DEBUG", "message": "Generated new correlation ID: ee767861314747069260805fc53e8413", "@timestamp": "2026-04-13T09:31:26.011071Z", "hostname": "004a16e755bb", "process_id": 1}
context-forge | {"asctime": "2026-04-13T09:31:26", "name": "mcpgateway.middleware.http_auth_middleware", "levelname": "DEBUG", "message": "HttpAuthMiddleware: has_pre=False has_post=False, skipping hooks", "@timestamp": "2026-04-13T09:31:26.012234Z", "hostname": "004a16e755bb", "process_id": 1, "request_id": "ee767861314747069260805fc53e8413"}
context-forge | {"asctime": "2026-04-13T09:31:26", "name": "mcpgateway.services.structured_logger", "levelname": "WARNING", "message": "[http_gateway] Request completed: GET /.well-known/oauth-authorization-server - 404", "component": "http_gateway", "category": null, "user_id": null, "user_email": null, "team_id": null, "duration_ms": 8.22758674621582, "custom_fields": null, "tags": null, "correlation_id": "ee767861314747069260805fc53e8413", "operation_type": "http_request", "request_method": "GET", "request_path": "/.well-known/oauth-authorization-server", "response_status_code": 404, "user_agent": "PostmanRuntime/7.51.1", "client_ip": "X.X.X.X", "metadata": {"event": "request_completed", "response_time_category": "fast"}, "hostname": "004a16e755bb", "process_id": 1, "timestamp": "2026-04-13T09:31:26.020477+00:00", "@timestamp": "2026-04-13T09:31:26.020556Z", "request_id": "ee767861314747069260805fc53e8413"}
context-forge | {"asctime": "2026-04-13T09:31:26", "name": "uvicorn.access", "levelname": "INFO", "message": "X.X.X.X:50900 - "GET /.well-known/oauth-authorization-server HTTP/1.1" 404", "@timestamp": "2026-04-13T09:31:26.021732Z", "hostname": "004a16e755bb", "process_id": 1}