Allow hosts to verify opaque OAuth access tokens - #48
Merged
Merged
Conversation
OAuth mode verified every bearer as a Supabase user JWT, so an application running its own OAuth authorization server could not accept the opaque, resource-bound access tokens it issues to MCP clients. An optional verifier now receives the token with the canonical MCP resource URL and configured issuer, and owns issuer, exact resource, expiry, and revocation checks. This mode requires an explicit issuer. Chumbo rejects a missing subject or past expiry and gives handlers an anonymous Supabase client, so the opaque bearer never becomes a Supabase user token. Without a verifier, Supabase JWT verification is unchanged. Verified with pnpm check and pnpm format:check.
Publish the application-owned OAuth verifier under 0.12.2, keeping package metadata, runtime version, specification, and changelog aligned. Verified with pnpm check, pnpm format:check, and npm pack --dry-run.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
OAuth mode verifies every bearer as a Supabase user JWT. An application that runs its own OAuth authorization server issues opaque access tokens bound to its MCP resource, and Chumbo could not authenticate them. Using such a token as a Supabase user credential would also be wrong.
What changed
auth: { mode: "oauth", issuer, verify }accepts an optional verifier. Chumbo callsverify({ token, resourceUrl, issuer })with the canonical resource URL and configured issuer.issuer, which protected-resource metadata advertises.verifykeeps Supabase JWT verification unchanged.0.12.2.Safety boundary
The verifier owns issuer, exact resource, expiry, and revocation checks. Handlers for these callers cannot rely on Supabase RLS; capability code enforces application permissions, as it already does for API-key callers.
Verification
pnpm check: 220 passed, 3 skipped; build, packed artifact, branded CLI, and generated-project checks passedpnpm format:checknpm pack --dry-run: 68-filechumbo@0.12.2artifact