[brandonkelly]

Summary

Authorization: Bearer <JWT>  ──▶ OAuth::authenticate('graphql') ──▶ user + graphql:read|write
                                         │
                                         ▼
                     Gql::getSchemaForUser($user, $canMutate)
                     components where `authenticated` => true | fn(User): bool
                                         │
                        ┌────────────────┴────────────────┐
                        ▼                                 ▼
          entry/asset queries: editable()      mutations: Elements::canSave/
          (peer entries, drafts, assets)       canDelete/canCreateDrafts($user)

Authorization: Bearer <GqlToken> ──▶ unchanged

Implements CMS-2559 on top of #20145. The GraphQL API is now an OAuth resource (graphql) with graphql:read and graphql:write levels. Requests with an OAuth token get a schema built per request from the schema components available to that user. Built-in components map to user permissions, such as sections.<uid>:read → viewEntries:<uid>. Plugins opt in with an authenticated key on their component config.

Notes for review:

• The schema isn't stored in the OAuth scope. If the token's scopes were component IDs, deleting a section would invalidate every token that included it, because Repositories rejects tokens with unknown scopes, and new sections would never reach existing tokens.
• Root entries queries for authenticated users don't return nested entries. Those are reached through their owners.
• Categories, tags, and global sets are deprecated, so their components aren't available to authenticated requests.
• Drafts and revisions are available to users with control panel access. Entries' drafts, revisions, currentRevision, parent, ancestors, children, and descendants fields only return entries the user can view, and createDraft always sets the authenticated user as the creator.
• Backport MCP servers and OAuth to Craft 5.12 #20145 has no UI for getting a token, because MCP clients handle that themselves. This PR adds My Account → Tokens. Any OAuth resource can opt in with Resource::$personalTokens (and a label); graphql does, mcp doesn't. The screen is hidden when no resource offers tokens to the user, so it only appears when enableGql is on or a plugin opts in. New token asks for the password first (elevated session with at least 5 minutes left, as in 2FA setup), then opens a slideout with a name, a checkbox list of the resource's scopes the user may be granted, and an expiry. The token is shown once. The screen also lists apps the user authorized through OAuth, and each grant can be revoked. Personal tokens are JWTs minted by OAuth::createPersonalAccessToken(). As in Laravel Passport, they're issued through one shared personal access client (grant_types: ["personal_access"], provider: "craft", no scopes). That's the client Passport's personalAccessClient() finds in Craft 6, whose Passport guard uses the craft user provider. A client with no provider would only match if Craft 6 configured an api guard. Each token's name is stored on its token row, and its scopes decide which resource it belongs to. Revoking a personal token revokes just that token. This builds on Use Laravel Passport's OAuth table layout and scope-bound clients #20154, which gives the OAuth tables Passport 13's layout, without a resource_id column, so Craft 6 can adopt 5.12 tokens. Craft 6's createToken() would reuse the same client, so a Passport-based Tokens screen there could list 5.12 tokens too.
• Query results are cached per user, with keys that include a hash of the user's current permissions. Each user's scope is cached too, keyed on configVersion and the same hash, so a permission or content model change rebuilds it.
• ElementQueryConditionBuilder now applies non-array eager-loading conditions (e.g. editable) as-is instead of intersecting them.

Evidence

• AuthenticatedSchemaTest (fixtures, Gql::executeQuery):
  • user with viewEntries on test1 (own only) and viewEntries + viewPeerEntries on withUri1 → entries returns only their own test1 entry plus the withUri1 entries
  • schema includes sections.test1:delete, but deleteEntry on another author's entry → Unable to perform the action.; on their own entry → true
  • read-only schema → no deleteEntry
  • Before: with the editable() and canDelete checks removed, the query and mutation tests fail. After: OK (4 tests, 14 assertions)
• GraphqlOAuthCest (real OAuth tokens through GraphqlController): a token for a user with viewUsers can query users, a token for a user without it gets Cannot query field "users", and an invalid token gets 401 with WWW-Authenticate: Bearer ... resource_metadata="…/.well-known/oauth-protected-resource/actions/graphql/api".
• AuthenticatedSchemaTest::testDraftsAreLimitedToUserPermissions: another author's drafts are hidden from a user without viewPeerEntryDrafts.
• GraphqlOAuthCest::testPersonalAccessTokenScopes: GraphQL is the only resource offering tokens; picking graphql:write also grants graphql:read; MCP tokens and foreign scopes are rejected; with enableGql off no resource offers tokens (so the screen is hidden).
• GraphqlOAuthCest::testPersonalAccessTokens also checks that two personal tokens share the personal_access client, the token row stores the name, and revoking one leaves the other working.
• GraphqlOAuthCest::testPersonalAccessTokens: a personal token queries users. getUserGrants() lists it as personal with graphql:read, alongside an OAuth-authorized client. After revokeUserGrant() the token gets 401 and only the OAuth client remains.
• Tokens screen, checked in a browser: New token prompts for the password, the slideout validates a blank name and no scopes, and a created token is shown once and answers {ping} with pong. Revoke confirms and the token then gets 401.
• vendor/bin/codecept run unit,functional: 4,191 tests. The only errors were the 18 OAuthTest tests, because its stub app has no getGql(); with enableGql => false in that stub they pass (18 tests, 78 assertions). PHPStan and ECS pass in the pre-commit hook.

Performance (semi-complex site from #20149: 3 sites, 112 fields, 72 entry types, 30 sections; an editor with 197 permissions; entries(limit: 20); median of 11 fresh processes, PostgreSQL):

	Uncached result	Cached result
Before result/scope caching	351 ms	— (not cached)
Result caching only	351 ms	80 ms
Result + scope caching	326 ms	65 ms (54 ms with lazyGqlTypes)

AuthenticatedSchemaTest also covers: a second user doesn't get the first user's cached results, losing viewPeerEntries isn't masked by a cached result, and a permission change rebuilds the cached scope. Both fail if the permissions hash is left out of their cache keys.

Related issues

• CMS-2559