/.well-known/jwks.json returns 404 ( integration with Entra ID )

[netdev360]

Hi All,

When deploying MCP Gateway with RS256 (asymmetric JWT signing - 1.0.0-BETA-1 ) - which is the recommended production configuration - there's currently no automated way for clients to retrieve the public key for token verification.

Current workflow:

1. Generate RSA key pair on gateway server
2. Configure gateway with private key path
3. Manually copy public key to every client that needs to verify tokens
4. Update all clients when keys are rotated

The gateway also consumes JWKS from external IdPs (Keycloak, Okta, Entra ID) for SSO token validation via the jwks_uri in OpenID discovery.
It looks as if .. the gateway just needs the JWKS publishing piece ... am I missing something here or is this on roadmap?
Thank you for your support,

Mihai

[crivetimihai]

Hi @netdev360, thanks for the reporting. Please confirm whether /well-known/jwks.json is served by your gateway or by your identity provider and share server logs around the 404 plus your OIDC/JWKS base URL; I can confirm the right path and update setup docs accordingly.

[netdev360]

Hi @crivetimihai thank you for getting back.

the short answer ... is neither.

long answer, the gateway signs with the private key without publishing the public key. There's no route that converts the PEM public key into JWK format and serves it over HTTP. I don't think the gateway serve JWKS at all.
in my lab, i had to generate the key pair, configure the gateway to sign with the private key, and copy the public key to every client/service that needs to verify tokens. This doesn't scale, and it breaks on key rotation, there is no buy in from the enterprise etc.

What's actually needed is for the gateway to:

• Read the RSA public key from JWT_PUBLIC_KEY_PATH
• Convert it to JWK format (RFC 7517)
• Serve it at /.well-known/jwks.json with kid matching the JWT header
• Optionally serve /.well-known/openid-configuration pointing to the jwks_uri
• Without this, every Agent that needs to verify gateway JWTs ... requires manual key distribution

I'm not a developer, so I had to ask Claude to fix this for me ... under the gun to finish the lab:

• custom image (mcpgateway:jwks-v4) that adds a /.well-known/jwks.json route — it reads the RSA public key from JWT_PUBLIC_KEY_PATH, converts it to JWK format with a kid, and serves it over HTTP.
• also added /auth/token-exchange (RFC 8693) so SPIRE-attested workloads can exchange Entra ID tokens for gateway JWTs without pre-shared secrets. With both in place, the gateway acts as a OAuth 2.1 authorization server — it signs RS256 tokens and publishes its keys for automated discovery.

Why all this trouble? Layered-defense ... multiple gateways (LLM vs MCP gateway), enterprise setup under Zero Trust Architecture principles etc.

Awesome work with the gateway, kudos to you & team!

Mihai :)

[crivetimihai]

Hi @netdev360, you're correct — the gateway currently does not publish a /.well-known/jwks.json endpoint for its own signing keys.

To clarify the architecture:

• The gateway consumes JWKS from external IdPs (Keycloak, Okta, Entra ID) via their jwks_uri for SSO token validation — this works.
• The gateway does not publish its own JWKS for clients to discover the gateway's public key. When using RS256, clients must obtain the public key out-of-band (manual copy).

For your use case (RS256 with Entra ID integration), the flow depends on direction:

1. If Entra ID issues tokens that the gateway validates: Configure SSO_GENERIC_JWKS_URI to point to Entra's JWKS endpoint (e.g., https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys). The gateway will fetch and cache the public keys.

2. If the gateway issues tokens that external services need to validate: You're right that a JWKS publishing endpoint would be valuable. Currently, you need to distribute the public key manually or via JWT_PUBLIC_KEY_PATH.

Publishing a JWKS endpoint for gateway-issued keys is a reasonable feature request. I'll open an issue to track adding /.well-known/jwks.json that exposes the gateway's public key(s) in JWK format.

[crivetimihai]

Hi @netdev360, confirming your finding — tested against the running instance and /.well-known/jwks.json returns 404. The gateway does not publish its own JWKS endpoint.

Architecture summary:

Direction	Status
External IdP → Gateway (gateway validates external tokens)	Supported via SSO_GENERIC_JWKS_URI or per-provider OIDC discovery
Gateway → External services (services validate gateway-issued tokens)	Not supported — no JWKS publishing endpoint

For your Entra ID integration:

If Entra ID issues tokens that the gateway validates, set:

SSO_GENERIC_JWKS_URI=https://login.microsoftonline.com/{tenant}/discovery/v2.0/keys

If the gateway issues tokens that external services need to validate — you're right, this doesn't scale with manual key distribution.

Workaround: A lightweight sidecar that reads JWT_PUBLIC_KEY_PATH, converts PEM → JWK, and serves it at a JWKS endpoint. A simple Flask/FastAPI service would do this in ~20 lines.

Related: Issue #3567 (Support for External OIDC Bearer Tokens) covers the broader use case of trusting external IdP tokens on API/MCP endpoints. A built-in JWKS publishing endpoint would complement that feature.

I'll ensure a feature request is opened specifically for JWKS publishing if one doesn't exist already.

[netdev360]

@crivetimihai - Thank you for your support!
As a side note, I'm not a developer but I do get to run all sorts of Labs ( ex. integrations testing included).
What is the policy with regards to source code generated with coding Agents ( ex Claude)?
Would your team find value in reviewing AI-generated code from Claude?