security(consent): refuse a delegated token at /authorize/consent

[lakhansamani]

Closes the last of the six advisories that were sitting in triage. GHSA-hhhh-p743-q3cp.

The gap

ConsentHandler authorizes the approval on one condition: tokenData.UserID == pending.UserID. GetUserIDFromSessionOrAccessToken resolves an RFC 8693 delegated token to the delegating user's sub — by design, so that a correctly-gated caller can treat a delegated token as "this user, with this reduced scope". That identity check therefore passes for an agent acting on the user's behalf.

It is the right answer for a caller that consults internal/delegatedscope, and the wrong one here: /authorize/consent is a plain gin route (http_routes.go) behind neither of the two places that gate actually enforces — the gRPC auth interceptor and the GraphQL field middleware. tokenData.Scope and tokenData.ActorID are never read.

The fix: fail closed, no new scope

A guard rejecting any caller with a non-empty ActorID.

Deliberately not a delegatedscope table entry. Approving a consent grant is not attenuable: the approval confers whatever scope the third-party client requested, which is unbounded by the agent's own ceiling. An agent capped at openid could hand a third party far more than openid, so a ceiling that permitted this would stop being a ceiling. That is why there is no scope for the operation rather than a scope nobody is granted — matching delegatedscope's own documented default ("an operation absent from the table is DENIED to delegated callers") and mirroring enforceDelegatedScope's not-delegatable branch, including its metric label.

Human-in-the-loop approval for a headless agent is CIBA + RAR (Wave 3 in the delegation design), not this endpoint. Noted in the code comment so the refusal reads as "use the right primitive" rather than "unsupported".

Nothing in the browser flow changes

The resolver checks the session cookie before the bearer token (auth_token.go), and the session branch never sets ActorID. So a first-party caller — including an agent driving the user's own browser with their cookie — takes the session path and is unaffected. Only a cookie-less caller presenting a delegated bearer token is refused.

There is a test for exactly this (a first-party session still approves and mints a code), because "does this break agent flows?" is the first question the change invites.

Measured impact — narrower than the report states

The advisory says the attack works "with no session cookie at all" and that "the resulting authorization code is delivered to the client's redirect_uri". Tested on main before the fix:

• The consent approval does succeed with an openid-only delegated token and no cookie — the core finding is real, and the grant is recorded.
• But the caller is redirected to the authorizer's own login UI, not to the client. The pre-generated handoff code it can see in that URL is not redeemable: exchanging it at /oauth/token returns 400 invalid_grant, because it is not yet bound to an authenticated user.
• A with-session control confirms the test setup is sound: the same request with a cookie does mint a code to the client, so the only missing element is the session.

Real exposure: consent can be pre-approved for one exact request (the grant is single-use and keyed to user + client + exact query), so a later visit from the victim's own browser skips the consent screen. Serious enough to fix — that screen is the only protection for a self-asserted client — but the caller obtains nothing usable itself. The advisory's severity and impact text should be corrected before publication.

Testing

internal/integration_tests/consent_delegated_test.go:

1. a delegated token is refused (403) — fails before the fix
2. a first-party session still approves and the flow mints a code at the client's registered redirect_uri
3. the login-handoff code is not redeemable without authentication

The client is RFC 7591 self-registered (ClientKindDynamic) on purpose: it resolves from the registry with no outbound fetch, so /authorize reaches the session and consent-grant checks. A CIMD client_id that serves no document is refused with invalid_client before either check — which is what made an earlier draft of this test inconclusive.

Mutation-verified: disabling the guard (in a form that still compiles) makes test 1 fail.

Local: go build ./..., go vet ./... clean; make test 0 failures; the three pre-existing consent tests (TestCIMDConsentFlow, TestConsentHandlerSecurityProperties, DCR) all still pass.