Custom Hostname active but /.well-known/oauth-authorization-server still returns issuer: <project-ref>.supabase.co (RFC 8414 violation)

[juliuszfedyk]

Summary

When Supabase Auth is configured with a Custom Hostname (e.g. auth.example.com, status: active, valid SSL, traffic correctly routed), the OAuth 2.0 Authorization Server Metadata discovery endpoint still returns an issuer value pointing to https://<project-ref>.supabase.co/auth/v1 — not to the custom hostname.

This violates RFC 8414 §3, which requires:

"The issuer value returned MUST be identical to the Issuer Identifier value into the Well-Known URI string."

In other words: if a client fetches https://auth.example.com/.well-known/oauth-authorization-server/auth/v1, the issuer in the response must match https://auth.example.com/auth/v1. Returning a *.supabase.co issuer instead is a spec violation and breaks compliant OAuth/OIDC clients.

---

Environment

• Platform: Hosted Supabase (cloud, not self-hosted)
• Feature: Auth Custom Hostname
• Custom Hostname status: active
• SSL: Valid, TLS routing confirmed working
• Auth version: Latest hosted (managed by Supabase)

---

Steps to Reproduce

1. Create a hosted Supabase project.
2. Configure a Custom Hostname for Auth (e.g. auth.<your-domain>) via the Supabase Dashboard and wait for status to become active.
3. Confirm routing works: curl -I https://auth.<your-domain>/auth/v1/health → 200 OK.
4. Fetch the OAuth discovery document:

curl https://auth.<your-domain>/.well-known/oauth-authorization-server/auth/v1

---

Actual Behavior

The JSON discovery document contains:

{
  "issuer": "https://<project-ref>.supabase.co/auth/v1",
  ...
}

The issuer is the raw Supabase project URL, not the Custom Hostname used to fetch the document.

---

Expected Behavior

Per RFC 8414, the issuer value must match the base URL used by clients to fetch the discovery document. When the endpoint is accessed via https://auth.<your-domain>/..., the response should contain:

{
  "issuer": "https://auth.<your-domain>/auth/v1",
  ...
}

The Custom Hostname should be fully reflected in the discovery document — not just as a routing layer.

---

Impact

Standards compliance

• RFC 8414 requires issuer and discovery URL to match. This is not optional — it is a MUST requirement.
• OIDC Discovery (OpenID Connect Discovery 1.0) imposes the same requirement on issuer.

MCP and OAuth 2.1 clients

• Remote MCP connectors (e.g. Claude Desktop, ChatGPT, Perplexity, and other MCP-compatible AI clients) perform strict issuer validation when connecting to an Authorization Server. An issuer/discovery-URL mismatch will either cause a hard failure or force insecure overrides.
• Supabase is actively being promoted as an OAuth 2.1 / MCP Authorization Server (see discussion #38022), but with this bug, hosted Supabase + Custom Hostname cannot serve that role for compliant clients.
• Users who follow the recommended Custom Hostname setup expecting a "proper" OAuth AS with their own domain will silently get a broken configuration.

No workaround via supported APIs

• The jwt_issuer field in config.toml is silently dropped by the hosted Supabase Management API (PATCH /v1/projects/{ref}/config/auth). It is only respected in self-hosted deployments.
• There is no field in the Dashboard UI or Management API to override the issuer for hosted Custom Hostname setups.
• The only safe current workaround is to use the raw <project-ref>.supabase.co URL as the issuer (defeating the purpose of Custom Hostname) or to proxy/wrap the discovery endpoint yourself.

---

Configuration Details

• Custom Hostname is active and handles TLS correctly — this is a platform-level issuer rewrite problem, not a routing or SSL issue.
• The /.well-known/oauth-authorization-server/auth/v1 endpoint is served correctly through the custom hostname; only the issuer value inside the response body is wrong.
• Related: jwt_issuer in config.toml is documented for self-hosted only; no equivalent exists for hosted projects with Custom Hostname.

Note: I discovered this platform limitation while auditing my own auth configuration after an unrelated accidental supabase config push incident (since fully recovered). The issuer mismatch exists independently of that incident and affects any hosted project using Custom Hostname as an OAuth AS.

---

Requested Fix

Add a platform-level capability so that for hosted Supabase + Custom Hostname, the OAuth/OIDC discovery document is correctly rewritten to reflect the custom domain. Specifically:

Option A (preferred): When Custom Hostname is active, automatically rewrite issuer (and all related URLs: authorization_endpoint, token_endpoint, jwks_uri, etc.) in the discovery document to use the custom hostname.

Option B: Expose a supported issuer_url (or equivalent) field via the Management API and Dashboard UI that hosted projects can set to override the issuer independently of the raw project ref.

Either option would make hosted Supabase + Custom Hostname a valid, RFC 8414-compliant OAuth Authorization Server usable by MCP clients and other strict OIDC consumers.