Supabase | The Open Source Firebase Alternative

Supabase Auth custom domain + OAuth issuer mismatch with MCP client

Auth

MCP

Hi Supabase folks, I’m trying to confirm expected behavior around Supabase Auth custom domains and OAuth/OIDC metadata.

I’m building a customer-facing MCP server that uses Supabase Auth as the OAuth authorization server. The client is a third-party MCP client using OAuth discovery.

Setup, with domains redacted:

MCP server:
https://mcp-app.example.com/api/mcp

Supabase Auth custom domain:
https://auth.example.com/auth/v1

My MCP protected resource metadata advertises the Supabase Auth custom domain:

{
  "resource": "https://mcp-app.example.com/api/mcp",
  "authorization_servers": [
    "https://auth.example.com/auth/v1"
  ]
}

The Supabase custom domain shows as active in the dashboard, and the OAuth consent page loads successfully.

The issue is that after the user approves consent, the MCP client comes back to my /api/mcp endpoint without an Authorization header. My server logs show:

GET /.well-known/oauth-protected-resource -> 200
GET /oauth/consent -> 200
POST /api/mcp -> 401

hasAuthorizationHeader: false
hasBearerToken: false

How to help

The user is experiencing an issue with Supabase Auth custom domains and OAuth issuer metadata. They are using Supabase Auth as the OAuth server for an MCP client, but the OAuth metadata still returns the project-ref URL instead of the custom domain. This discrepancy may be causing the MCP client to fail in attaching an authorization header after consent. The user seeks clarification on whether this behavior is expected and how to configure the issuer metadata to use the custom domain.

Help on Discord

Supabase custom domain for OAuth branding

User needs: branded OAuth flow without default Supabase URL

Replies (1)

My questions:

Is it expected that Supabase Auth custom domains still return the project-ref URL as the OAuth/OIDC issuer?
If yes, should an OAuth client discover Supabase via the project-ref URL instead of the custom domain, even when the custom domain is active?
Is there a supported way to make the OAuth issuer metadata use the custom Auth domain?
Could this issuer/custom-domain mismatch cause a strict OAuth client to complete the browser consent step but then reject the token exchange / not attach a bearer token to the MCP request?

I’m intentionally omitting real domains/project refs here, but happy to DM exact URLs to Supabase staff if helpful. Just trying to understand the expected custom-domain behavior for OAuth metadata.

songkeys·4/29/2026, 2:01:50 AM

https://auth.example.com/auth/v1/.well-known/oauth-authorization-server

issuer: https://<project-ref>.supabase.co/auth/v1
authorization_endpoint: https://<project-ref>.supabase.co/auth/v1/authorize
token_endpoint: https://<project-ref>.supabase.co/auth/v1/token