Hosted MCP OAuth: api.supabase.com/.well-known/openid-configuration returns 404 — OIDC-discovery clients (VS Code) can't start sign-in

[dadicool]

Bug Report: Supabase hosted MCP OAuth fails — /.well-known/openid-configuration returns 404, breaking OIDC discovery

To: https://github.com/supabase/mcp
Status: Ready to file
Reported: 2026-08-23

Title

Hosted MCP OAuth: api.supabase.com/.well-known/openid-configuration returns 404 — OIDC-discovery clients (VS Code) can't start the sign-in flow

Summary

The hosted Supabase MCP server (https://mcp.supabase.com/mcp) delegates OAuth to
the authorization server https://api.supabase.com. That authorization server
publishes its metadata only at the RFC 8414 path
(/.well-known/oauth-authorization-server) and returns 404 at the OIDC path
(/.well-known/openid-configuration). MCP clients that perform OIDC discovery
(probing openid-configuration) — including VS Code's dynamic-auth MCP client —
cannot construct the authorization URL, so the OAuth flow never starts. The result
is a registered dynamic client with no session and a server that stays at
401 No access token was provided.

Environment

• MCP client: VS Code (dynamic OAuth / PKCE)
• MCP endpoint: https://mcp.supabase.com/mcp?project_ref=<ref>&features=...
• Authorization server: https://api.supabase.com
• Date observed: 2026-08-23

Evidence

GET https://api.supabase.com/.well-known/openid-configuration:

HTTP/2 404
{"message":"Cannot GET /.well-known/openid-configuration"}

GET https://api.supabase.com/.well-known/oauth-authorization-server (RFC 8414):

HTTP/2 200
{
  "issuer": "https://api.supabase.com",
  "authorization_endpoint": "https://api.supabase.com/v1/oauth/authorize",
  "token_endpoint": "https://api.supabase.com/v1/oauth/token",
  "registration_endpoint": "https://api.supabase.com/platform/oauth/apps/register",
  "grant_types_supported": ["authorization_code","refresh_token","urn:ietf:params:oauth:grant-type:jwt-bearer"],
  "code_challenge_methods_supported": ["S256","plain"],
  ...
}

The MCP resource metadata (https://mcp.supabase.com/.well-known/oauth-protected-resource/mcp)
correctly points to authorization_servers: ["https://api.supabase.com"], but the
client then fails at the discovery step because the OIDC document is missing.

Expected behavior

https://api.supabase.com/.well-known/openid-configuration should return a valid
OpenID Connect discovery document (or redirect/alias to the RFC 8414 metadata), so
OIDC-discovery-based MCP clients can initiate the authorization flow.

Actual behavior

The OIDC path 404s. VS Code registers a dynamic client (clientId is created via
the working registration_endpoint) but never obtains an authorization URL, so no
session is ever established. All MCP calls return:

HTTP/2 401
www-authenticate: Bearer error="invalid_request",
  error_description="No access token was provided in this request",
  resource_metadata="https://mcp.supabase.com/.well-known/oauth-protected-resource/mcp?project_ref=..."

Impact

Any MCP client that relies on OIDC discovery (rather than RFC 8414
oauth-authorization-server) cannot authenticate to the hosted Supabase MCP
server. VS Code is affected; other clients that probe openid-configuration first
would be too.

Suggested fixes

• Serve the OIDC discovery document at
  https://api.supabase.com/.well-known/openid-configuration (even a thin alias of
  the RFC 8414 metadata with an issuer field is sufficient), or
• Confirm/document that clients must use RFC 8414 discovery only, and ensure the
  protected-resource metadata / client guidance reflects that.

Workaround

None client-side for VS Code's dynamic-auth flow — the discovery document is
missing server-side. (A personal access token / API-key header is not currently
supported by the hosted Supabase MCP server.)

[dadicool]

Root-cause analysis: the bug is in the hosted platform gateway, not the auth service

I traced the discovery layer through the open-source repos. The auth service code is already correct — this is a hosted-gateway routing gap.

The discovery endpoints live in supabase/auth (GoTrue), and both are served correctly

In internal/api/api.go, both well-known routes are registered and handled by the same handler:

r.Get("/.well-known/openid-configuration", api.WellKnownOpenID)                              // ungated
r.With(api.requireOAuthServerEnabled).Get("/.well-known/oauth-authorization-server", api.WellKnownOpenID)  // gated

In internal/api/jwks.go, WellKnownOpenID returns identical, spec-compliant metadata for both paths (OIDC Discovery is a superset of RFC 8414, so one response satisfies both):

response := OpenIDConfigurationResponse{
    Issuer:                config.JWT.Issuer,
    AuthorizationEndpoint: issuer + "/oauth/authorize",
    TokenEndpoint:         issuer + "/oauth/token",
    JWKSURL:               issuer + "/.well-known/jwks.json",
    ...
}

So the auth service already serves /.well-known/openid-configuration correctly.

Evidence that the hosted gateway routes one path but not the other

Against the hosted authorization server https://api.supabase.com:

Request	Result
GET /v1/oauth/authorize	400 (endpoint exists, needs params)
GET /.well-known/oauth-authorization-server	200 — fully populated
GET /.well-known/openid-configuration	404 Cannot GET

The OAuth endpoints and the RFC 8414 well-known path are routed at the platform edge, but the OIDC well-known path is not — even though the same backend handler serves both.

Conclusion / suggested fix

This is not fixable in supabase/mcp (which only contains the MCP tool server, no OAuth/gateway code) or in supabase/auth (whose discovery handler is already correct). The fix is a routing/ingress addition in the hosted api.supabase.com gateway: route /.well-known/openid-configuration to the same auth backend that already serves /.well-known/oauth-authorization-server.

Once that route is added, OIDC-discovery MCP clients (VS Code's dynamic-auth client) will be able to construct the authorization URL and complete the sign-in flow.

[Rodriguespn]

Thanks for opening the issue @dadicool. I had no problems on getting myself authenticated in Supabase MCP server on VS Code version 1.134.0 (Universal).

Steps followed to get the Supabase MCP server authenticated:

1. Open VS Code Command Pallet (Ctrl+Shift+P or CMD+Shift+P on Mac) and write "Remove Dynamic Authentication Providers" to clear any stale MCP credentials in VSCode (source)
2. Open the VS Code Command Pallet again and write "MCP: Browse MCP Servers"
3. On the left, search "Supabase" and click "Install"

4. Click in the gear-wheel (check picture below) and click in "Start Server"

5. Follow the authentication flow

You should have a live connection to Supabase MCP server on VS Code.

Let us know if the problem persists.