OAuth server: existing grant auto-approves without client details

Summary

GoTrue's OAuth server does not honour the standard OIDC prompt parameter (OIDC Core 1.0 §3.1.2.1). As a consequence, when the signed-in user already has a grant covering the requested scopes, GET /oauth/authorizations/{authorization_id} does two things at once:

1. it issues the authorization code and returns { "redirect_url": "...?code=..." }, and
2. it omits everything a consent UI would need to render — no client, no user, no scope.

Because both happen inside a single unparameterised GET, a custom authorization UI configured for GoTrue's OAuth server cannot present the "you are signed in as X, continue?" step that Google, Microsoft and Okta show on a repeat authorization. There is no point at which the code has not yet been issued and the client is still known.

Current behaviour

First authorization (no grant yet) — full details:

{
  "authorization_id": "...",
  "redirect_uri": "...",
  "client": { "id": "...", "name": "..." },
  "user": { "id": "...", "email": "..." },
  "scope": "openid profile"
}

Repeat authorization (grant exists, same scopes) — a destination only:

{ "redirect_url": "https://.../callback?code=..." }

The second shape carries no client identifier, so the UI cannot look up which application is asking, cannot name it on screen, and cannot offer "use a different account" against it. The code in that URL is already valid, so any confirmation rendered afterwards is cosmetic — the authorization has happened.

This same GET also binds the authorization to the currently signed-in user. Signing out and returning with the original authorization_id therefore fails on a user mismatch, which is why an account switch cannot simply resume the request it started from.

Expected behaviour

A. Honour prompt on the authorize request.

• With prompt=consent, return the full authorization details and defer code issuance until an explicit approve or deny action.
• With prompt=select_account, keep the authorization unbound until the user has selected an account, or provide a supported way to preserve and resume the original authorization request across an account switch.
• With prompt=none, complete silently only when an authenticated session and sufficient prior consent already exist; otherwise return the corresponding OIDC interaction error (login_required, consent_required, or account_selection_required).

B. Include client details alongside redirect_url.

Less complete — the code is still issued up front, so a "cancel" button would be untruthful — but it would at least let the screen name the application and the account.

(A) is preferable: it makes the confirmation step meaningful rather than decorative, and prompt is already the standard mechanism relying parties use to request exactly this.

Reproduction

1. Enable the OAuth server (GOTRUE_OAUTH_SERVER_ENABLED=true) and register a confidential client with openid profile.
2. Complete an authorization once and approve it.
3. Start a second authorization for the same user, client and scopes.
4. GET /oauth/authorizations/{authorization_id} returns the redirect_url shape. No request parameter changes this.

Why it matters

On a shared device, or for anyone holding more than one account, a repeat sign-in currently completes with no indication of which account was used and no way to switch. The relying party cannot compensate: it never sees the authorization server's session, and the only workaround available to the user is to visit the account site manually and sign out before returning.

Environment

• GoTrue with GOTRUE_OAUTH_SERVER_ENABLED=true, hosted Supabase
• Authorization code + PKCE (S256), confidential client
• Scopes: openid profile