OAuth server: an existing grant auto-approves and returns no client details, leaving no room for an account-confirmation step

[scarletkc]

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