fix(binjovi-mcp): the OAuth service must know every MCP scope #122
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/mcp-oauth-image-carries-repo-scope"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
create_repositorycould not be used even after #120 putbinjovi.repository.createon the client and the control plane policy grantedit. Every authorize request naming the scope answered
{"error":"invalid_request"}.The cause
Binjovi.MCPOAuth.Protocolbuilds@scopesat compile time fromBinjovi.Domain.MCPPermissions.scopes(), and the authorize endpoint refuses anyrequest naming a scope outside it. This image decides which scopes can ever be
granted. The control plane at
binjovi.sean.farmdecides which tools exist.They are pinned in different repositories, and nothing keeps them in step.
This Deployment ran
sha-833fc189660f, which predatescreate_repository:So the MCP tool was advertised by a current control plane, while the OAuth
service would never grant its scope. The symptom read as a stale token or a wrong
client scope. It was neither.
Measured, not guessed
The same authorize request was replayed against the live endpoint, varying only
the scope:
offline_accessbinjovi.repository.create{"error":"invalid_request"}The fix
Bumped to
sha-57d0ab2ab4be, the revision the control plane runs.The structural hazard
Two Deployments of one codebase, pinned independently, where one validates the
vocabulary the other advertises. A new MCP tool ships in
sean/binjovi, and thispin silently makes it unusable — with an error that names nothing. The comment on
the pin records this and says to bump it when a tool ships, but a comment is the
weakest possible guard. Worth a follow-up: either derive the scope list at
runtime, or gate a tool's release on the OAuth service advertising its scope.
tests/check.shgreen,tests/binjovi-mcp-oauth-service.shincluded.https://claude.ai/code/session_01JGe4pyhQ36AhgDfPJry4d3
Every authorize request naming binjovi.repository.create answered {"error":"invalid_request"}, so create_repository could never be used even with the scope on the client and the permission in the control plane policy. Binjovi.MCPOAuth.Protocol builds @scopes at COMPILE time from Binjovi.Domain.MCPPermissions.scopes(), and refuses any request naming a scope outside it. This Deployment was pinned to sha-833fc189660f, which predates create_repository: that revision has no occurrence of the tool at all. So the control plane advertised a tool whose scope this service would never grant. Measured, not guessed. The same authorize request was replayed against the live endpoint twice: without the scope it answers 302, with it 400. Bumped to sha-57d0ab2ab4be, the revision the control plane runs. The two images are pinned in different repositories and nothing keeps them in step; the comment says so, and says to bump this when a new MCP tool ships. Claude-Session: https://claude.ai/code/session_01JGe4pyhQ36AhgDfPJry4d3