OAuth 2.1 authorize redirects to invalid /oauth/consent path on hosted projects

[fcolavecchia]

Bug found with help from Claude Sonnet 3.6, confirmed by Gemini.

Description

The OAuth 2.1 Authorization Server feature is currently unusable on hosted Supabase projects. When initiating the authorization code flow, the server issues a 302 redirect to {SITE_URL}/oauth/consent.

However, this path is not served by the GoTrue API, nor is there a default UI deployed by the Supabase platform at that location, resulting in the error: { "error": "requested path is invalid" }.

To Reproduce

1. Enable an OAuth 2.1 client (e.g., for an MCP connector) in a hosted project.
2. Call the authorize endpoint:
   GET https://cjwyjqklzrufnbtnzxfa.supabase.co/auth/v1/oauth/authorize?client_id=...&response_type=code&scope=openid
3. The browser is redirected to https://cjwyjqklzrufnbtnzxfa.supabase.co/oauth/consent?authorization_id=...
4. The page returns a 404 or { "error": "requested path is invalid" }.

Technical Analysis

The redirect target is constructed in internal/api/oauthserver/authorize.go (lines 166–173):

baseURL := s.buildAuthorizationURL(config.SiteURL, config.OAuthServer.AuthorizationPath)
redirectURL := fmt.Sprintf("%s?authorization_id=%s", baseURL, authorization.AuthorizationID)
http.Redirect(w, r, redirectURL, http.StatusFound)

On hosted projects, AuthorizationPath defaults to /oauth/consent. Because this is a headless API, GoTrue expects a frontend to handle the UI at that path.

The Gap: The platform does not serve a default consent page, and the GOTRUE_OAUTH_SERVER_AUTHORIZATION_PATH environment variable is not exposed in the Dashboard. This prevents developers from pointing the redirect to a custom Edge Function or branded UI.

Documentation Discrepancy

Recent documentation (Feb 2026) suggests that an "Authorization Path" setting should exist under Authentication > OAuth Server, but this field is currently missing/hidden in project cjwyjqklzrufnbtnzxfa (Region: sa-east-1).

Expected Behavior

1. The Authorization Path configuration should be exposed in the Dashboard to allow custom consent URIs.
2. Alternatively, an absolute URL should be supported for AuthorizationPath to allow redirects to Edge Functions without misconfiguring the project's global SiteURL.

System Info

• Project Ref: cjwyjqklzrufnbtnzxfa
• Region: sa-east-1
• Date/Time: 2026-03-06 (UTC-3)
• Use Case: Internal ChatGPT MCP Connector (Branded UI required).

[nathanschram]

Nice detective work tracing through authorize.go - your analysis of the redirect logic is spot on. I think the missing piece might be that the OAuth 2.1 server is designed to be "headless" - the consent page at /oauth/consent is something you build yourself in your app, not something GoTrue serves.

The flow is meant to go like this: GoTrue redirects to your frontend, where you call supabase.auth.oauth.getAuthorizationDetails(authorizationId) to show the user what they're being asked to authorise, then approveAuthorization() or denyAuthorization() based on their choice.

I think the main issue here is your SITE_URL - from the redirect URL in your report, it looks like it's set to the Supabase project URL (cjwyjqklzrufnbtnzxfa.supabase.co) rather than your application's domain. So the redirect is hitting GoTrue itself instead of your app. If you update SITE_URL under Authentication > URL Configuration to point to your app (e.g. https://myapp.com), the redirect should land on your frontend where you can serve the consent UI.

For the consent page itself, there are Next.js and React examples in the OAuth Server docs that walk through the full flow.

As for the Authorization Path setting - it should be under Authentication > OAuth Server in the Dashboard (not OAuth Apps). If it's genuinely not showing up in your project (sa-east-1), that could be worth raising separately as a Dashboard rollout issue.