OAuth Dynamic Client Registration rejects custom URI schemes (inconsistency with PR #711)

[2DKot]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

The OAuth 2.0 Dynamic Client Registration endpoint (POST /oauth/clients/register) strictly enforces http or https schemes for redirect_uris, rejecting custom schemes (e.g., cursor://, exp://, myapp://) with a 400 error.

This behavior persists even when the custom scheme is explicitly whitelisted in additional_redirect_urls (or GOTRUE_URI_ALLOW_LIST).

This seems to be inconsistent with PR #711, which relaxed this validation for general auth flows (Magic Links, etc.) to support native applications. The OAuth Server implementation appears to still use the legacy/strict validation logic, making it impossible to register native clients (like Cursor IDE) that rely on dynamic registration.

To Reproduce

1. Configuration
Start a local Supabase instance with the custom scheme allowed in config.toml:

[auth]
additional_redirect_urls = ["cursor://*"]

2. API Call
Attempt to register a dynamic client using the custom scheme:

curl -i -X POST http://127.0.0.1:54321/auth/v1/oauth/clients/register \
  -H "Content-Type: application/json" \
  -d '{
    "client_name": "Cursor IDE",
    "redirect_uris": ["cursor://anysphere.cursor-mcp/callback"]
  }'

3. See Error
The server returns a 400 Bad Request:

{"code":400,"error_code":"validation_failed","msg":"400: invalid redirect_uri 'cursor://anysphere.cursor-mcp/callback': scheme must be HTTPS or HTTP (localhost only)"}

Expected behavior

The registration should succeed if the URI matches the allowed list configuration, similar to how /authorize and other endpoints now behave post-PR #711.

Supabase acting as an OAuth Provider should support native apps that require custom URI schemes (RFC 8252).

System information

• Docker Image: public.ecr.aws/supabase/auth:v2.183.0 (Latest stable at time of writing)
• Environment: Local Development (Supabase CLI)

Additional context

It appears the oauthserver package implementation was not updated alongside the changes in PR #711.

While PR #711 fixed internal/api/provider logic, the Dynamic Client Registration logic in internal/api/oauthserver seems to strictly validate the URI scheme before checking the configuration.

References:

1. PR fix: allow all URL forms in redirects #711 (Context): fix: allow all URL forms in redirects #711 - "feat: support custom schemas for redirect urls"
2. Suspected Location: The validation likely occurs within the validation flow triggered in internal/api/oauthserver/service.go (around line 197):
   

   auth/internal/api/oauthserver/service.go

   Line 197 in 2a38668

   return fmt.Errorf("scheme must be HTTPS or HTTP (localhost only)")

This blocks the development of MCP (Model Context Protocol) servers and other native integrations that utilize Supabase as an Auth Provider locally.