[shanurwan]

What

A test suite that checks the OAuth 2.1 server against what the MCP authorization specification requires of an authorization server. It drives the full router the way MCP clients (Claude, ChatGPT, Claude Code) do: discovery, registration, authorize, consent, token and refresh. Each of the 18 requirements cites the specification.

It also fixes one gap it found: token responses did not send Cache-Control: no-store (OAuth 2.1 §3.2.3).

Why

I run an MCP server (Counsel) behind this OAuth server, and Claude signs people in to it. It works, but every access token carries aud: "authenticated" whatever resource the client asked for, so the server can't tell a token issued for it from one issued for another MCP server on the same project. I had to turn the audience check off. The MCP Python SDK warns that validate_token_resource becomes the default in 3.0; servers built on it would then refuse every token from Supabase Auth. I wanted to know exactly which requirements hold today, and to know when that one is fixed.

Several open PRs close MCP sign-in gaps (#2871, #2894, #2895). This gives them a shared definition of done. A known gap is a pending test that names its issue and PR. It is skipped while the gap exists, and fails with "now conforms; remove the pending marker" once it is closed, so the list stays accurate.

Results on master (with the fix)

• 11 pass: metadata, S256 PKCE, dynamic registration, non-loopback http redirects refused, PKCE required and verified, exact redirect matching, code and state returned once, no-store bearer token response, single-use codes, refresh token rotation, redirect URI available to the consent screen.
• 7 known gaps:
  • AS-05 CIMD advertised (OAuth 2.1 server: support Client ID Metadata Documents (URL client_id) for MCP clients #2850, feat(oauthserver): support Client ID Metadata Documents #2895)
  • AS-09 loopback redirect on any port (OAuth 2.1 server: authorize rejects RFC 8252 loopback ephemeral-port redirect_uri (exact-match, no port exemption) #2703, fix(oauthserver): accept loopback redirect URIs on any port #2871)
  • AS-13, AS-14, AS-16 resource indicators and audience (OAuth 2.1 server: support RFC 8707 Resource Indicators (resource parameter → aud claim) #2610, feat(oauthserver): bind access tokens to RFC 8707 resource indicators #2894)
  • AS-18 iss in the authorization response (RFC 9207; SHOULD in MCP 2026-07-28; not filed yet)

The open PRs, each merged onto this branch

• fix(oauthserver): accept loopback redirect URIs on any port #2871: AS-09 passes.
• feat(oauthserver): support Client ID Metadata Documents #2895, with AllowClientIDMetadataDocuments on: AS-05 passes.
• feat(oauthserver): bind access tokens to RFC 8707 resource indicators #2894: its migration 20261030120000_add_resource_to_sessions has the same version as 20261030120000_add_dedicated_scope_to_saml_providers from feat(saml): add dedicated_scope option for SAML providers #2893, merged on 6 Nov. Rebased on master, only one of them runs, so sessions.resource is never created and new sessions fail ("column "resource" of relation "sessions" does not exist"). With the migration given a later timestamp, AS-13, AS-14 and AS-16 pass.
• No PR made a passing requirement fail.

On master, AS-14 also shows that a form-encoded token request for a different resource than the authorized one is accepted, because the check only reads JSON bodies. #2894 fixes this.

Not covered

Fetching Client ID Metadata Documents, DPoP, and the consent page itself, which each project builds.

Testing

go test ./internal/api/ -run TestMCPAuthorizationConformance -v
go test ./internal/api/... -p 1

Both pass locally against Postgres 15.

[shanurwan]

Split the Cache-Control: no-store fix into #2919 so it can land on its own. Once that merges I'll rebase this, and it will be only the conformance suite (AS-11 checks the header, so it relies on #2919).