Bug report

When a public OAuth client refreshes with a nonexistent token, Supabase's /auth/v1/oauth/token endpoint returns HTTP 400:

{
  "code": 400,
  "error_code": "refresh_token_not_found",
  "msg": "Invalid Refresh Token: Refresh Token Not Found"
}

Under RFC 6749 section 5.2, we expect an OAuth error response such as:

{
  "error": "invalid_grant",
  "error_description": "Refresh token is invalid or expired."
}

Reproduction

Use an existing public OAuth client with token_endpoint_auth_method=none:

curl -i 'https://PROJECT_REF.supabase.co/auth/v1/oauth/token' \
  --data-urlencode 'grant_type=refresh_token' \
  --data-urlencode 'client_id=PUBLIC_CLIENT_ID' \
  --data-urlencode 'refresh_token=synthetic-nonexistent-refresh-token'

We reproduced this on hosted Supabase on September 22 and 23, 2026. No valid refresh token is needed for the reproduction.

Impact

The official MCP TypeScript SDK 1.29.0 parses the current response as ServerError and retains stale credentials. With invalid_grant, it clears those credentials. Both responses start authorization in our offline SDK test using mocked HTTP responses and synthetic credentials.

ChatGPT displayed -32603: Internal error during matching refresh failures. We cannot confirm whether correcting this response alone will fix ChatGPT's recovery behavior.

Possible source

In handleRefreshTokenGrant, the OAuth handler passes through the shared token service's HTTPError without converting it into an OAuth error.

Source examined: internal/api/oauthserver/handlers.go at ce9a8eee. This is the upstream revision examined, not a verified hosted running revision.

Could you confirm this and return invalid_grant for invalid or revoked refresh tokens at the OAuth endpoint, while preserving the first-party Auth error format? Operational failures should remain distinct from invalid authorization.