Part of the fine-grained OAuth token sequence (TID #605869, tasks **T3** consent capture and **T5** minting). Depends on the OAuth token model work. ## Scope Doorkeeper hooks so a token minted from a granular consent is flagged and resolvable, at both **authorization** and **refresh**. ## Why the consent anchor makes this small Because the token derives its permissions from the consent grant rather than carrying its own copy, refresh has nothing to copy forward. Contrast the token-anchored alternative, which would require copying scope rows onto each new token. That copy-forward pattern is worth avoiding deliberately, not just for convenience. It is precisely the shape that made PAT rotation escalatable: `PersonalAccessTokens::RotateService#create_token_params` copies `scopes`, `granular`, `sudo` and the full granular scope set onto the new token, with no check binding the operation to the calling credential — see the rotation vulnerability tracked separately under the gPAT work. The PRD (#468924) states "issue short-lived tokens whose refresh can never escalate scope" as a goal. With the consent anchor that property falls out of the data model instead of depending on a check somebody has to remember to write. **Please record this as a reason for D1**, not merely a convenience. ## Consent grant writes The grant is written to the new `oauth_consent_grants` table (#608634), not to `oauth_consents`. Doorkeeper is the only writer in phase 1; the IAM consent flow writes the same table at the Q3 cutover. No changes to `Authn::OauthConsent` or its validations, and no AuthN sign-off is needed for the write path. Write path: the authorize screen's granular selection becomes one `authorized` grant with `source: doorkeeper` plus its `granular_scopes` rows. A re-consent replaces the active grant; the previous row becomes `revoked` and stays as history. Creating, amending and revoking a grant each emit an audit event. Revoking a grant must also revoke that user and application's outstanding Doorkeeper tokens. Without that, the consent skip for a confidential app with a live token (`app/controllers/oauth/authorizations_controller.rb:30`) would keep minting tokens against a revoked grant. Hook grant revocation into the paths that already revoke an app's tokens: the authorized-applications page (`Authn::OauthApplications::RevokeService`), admin revocation, and user blocking. RFC 7009 single-token revocation does not revoke the grant, since sibling tokens may still be in use. ## Open question: write a grant for legacy authorizations too? Should Doorkeeper write an `oauth_consent_grants` row for **every** authorization (legacy coarse scopes included), not only granular ones? Reasons to prefer yes: - **Cutover parity.** Under AUTH-002 the IAM consent flow records *all* authorizations. Writing a grant from Doorkeeper now yields one grant-backed population at migration, instead of a permanent split between grant-backed and token-derived authorized apps. - **One revocation path.** Revoking an app then always means revoking its grant, for legacy and granular apps alike. Boundaries if accepted: record-only (no legacy enforcement path reads it) and no historical backfill. If not, the granular-only write remains the minimum for this task. Decide with AuthN and record the outcome here. ## Trusted clients skip the consent screen — auto-persist consent Doorkeeper skips the authorize screen for trusted applications (`skip_authorization { client.application.trusted? }` — `config/initializers/doorkeeper.rb:101`). Under the consent grant anchor, request-time resolution requires a grant row to exist, so a skipped screen must still record one. Mirror what the IAM flow already does: `Iam::ConsentController#show` handles `skip_consent` by auto-accepting with granted = requested, which still persists the consent record through `AcceptConsentChallengeService`. The Doorkeeper path must do the same: `skip_authorization` auto-persists an `authorized` grant with `source: trusted_auto_grant`, no screen shown. The permission and boundary set that grant gets depends on the granular scope request contract, which is still open in the proposal (per-application registration of the scope set, a request parameter, or both). Settle that before this path ships. Note there is a second skip path: confidential apps with a matching live token also skip the screen (`app/controllers/oauth/authorizations_controller.rb:30`). This is safe for granular apps — their first authorization always shows a screen and records the consent — but under legacy-authorization recording, already-authorized apps will not get a grant row until they re-authorize. Raised by Adil in the [TID thread](https://gitlab.com/gitlab-org/gitlab/-/work_items/605869#note_3660352899). ## Acceptance criteria - [ ] Consent grant written on the Doorkeeper authorization-code flow; a re-consent replaces the active grant - [ ] Refresh preserves, and provably cannot widen, the granted permission set - [ ] Spec asserting refresh cannot escalate - [ ] Revoking a grant revokes that user and application's outstanding tokens; hooked into the authorized-applications page, admin revocation and user blocking - [ ] Audit events on grant create, amend and revoke - [ ] Legacy-authorization grant question decided with AuthN; outcome recorded here - [ ] Trusted-client (`skip_authorization`) path persists an authorized grant without showing the screen, with the scope set per the settled request contract