Add vendor-neutral HTTP OAuth and delegated token exchange - #4
Merged
Merged
Conversation
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.
Add optional HTTP OAuth so users can connect through their host's sign-in and consent flow without creating an fmsg API key. API-key HTTP and stdio remain the default. The Web API continues to enforce messaging visibility, recipients, grants and quotas.
The server publishes protected-resource metadata, discovers the configured issuer's OAuth JWKS, validates incoming EdDSA access tokens for the exact MCP resource, and checks messaging scopes before dispatch. It uses authenticated RFC 8693 exchange for a separate Web API token, with no incoming-token forwarding or
X-FMSG-Act-As. Caches are isolated per incoming token and capped at five minutes and both token lifetimes. Waits renew expiring sockets and catch up within their original cursor and deadline.Authentication failures produce 401/403 challenges; exchange configuration errors produce 5xx and sanitized operator-action logs. If a wait has already streamed progress, a later auth failure finishes as an MCP error and the next request receives the challenge. Operator documentation covers vendor-neutral setup, client registration options, TLS metadata routing and revocation limits.
Validation: typecheck, build, 127 tests (including 26 signed-token OAuth cases), and npm package preview. Tests cover invalid claims, key rotation, scopes, exchange fields, token isolation, revocation, reconnects and cancellation. The fake Web API accepts registered token fixtures; actual hosted-client and deployed IdP/Web API acceptance remain rollout checks. CI passes on the final commit: Node 22/24, Docker image and real two-host API-key acceptance. No deployment or release is included.