koala73 / koala73/worldmonitor
security(mcp/oauth): adopt issuer-bound auth, CIMD, and enterprise-managed authorization
- Dominant language
- TypeScript
- Stars
- 86.6k
- Forks
- 13.1k
- Avg merge
- 8h 4m
- Merged PRs (30d)
- 825
Description
## Summary\n\nHarden WorldMonitor's MCP OAuth implementation for MCP 2026-07-28 and establish an enterprise authorization path.\n\nDepends on #5817 for the new protocol/extension negotiation foundation.\n\nReferences:\n- https://blog.modelcontextprotocol.io/posts/2026-07-28/#authorization\n- https://modelcontextprotocol.io/extensions/auth/overview\n- https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization\n- https://claude.com/blog/enterprise-managed-auth\n\n## Current state\n\nWorldMonitor publishes RFC 8414 and RFC 9728 metadata and supports authorization-code + PKCE, refresh tokens, and RFC 7591 Dynamic Client Registration. DCR is now deprecated in favor of Client ID Metadata Documents (CIMD), and the new specification tightens issuer binding and authorization-response validation.\n\nRelevant surfaces:\n- api/oauth-authorization-server.ts\n- api/oauth-protected-resource.ts\n- api/oauth/register.js\n- api/oauth/authorize.js\n- api/oauth/token.js\n- public/auth.md\n- public/.well-known/\n- MCP entitlement and token storage paths\n\n## Scope\n\n### Issuer hardening\n\n- Emit the RFC 9207 iss authorization-response parameter.\n- Validate the exact expected issuer before any authorization code is redeemed.\n- Bind registered client credentials and redirect metadata to the issuer that created them.\n- Reject cross-issuer credential reuse, including apex/api host confusion and malicious metadata substitution.\n- Preserve PKCE, redirect allowlisting, one-shot code consumption, refresh-token rotation, and retryable billing-verification behavior.\n\n### CIMD migration\n\n- Support Client ID Metadata Documents as the preferred registration/discovery path.\n- Keep Dynamic Client Registration as a documented compatibility fallback during the deprecation window.\n- Define migration/precedence behavior when a client presents both CIMD identity and a legacy DCR registration.\n- Update authorization-server metadata, protected-resource metadata, auth.md, server card, and client compatibility tests.\n\n### Enterprise-Managed Authorization\n\n- Evaluate and, if compatible with the entitlement model, implement the official Enterprise-Managed Authorization extension.\n- Map organization/tenant and group-derived access to explicit WorldMonitor entitlements without creating shared dashboard identities or bypassing per-user auditability.\n- Support centralized revocation and short-lived access without requiring every employee to perform an individual connector grant.\n- Fail closed when tenant, issuer, group, or entitlement verification is unavailable.\n- Document which commercial tier/contract enables organization-wide provisioning; do not infer it from API-key counts.\n\n## Acceptance criteria\n\n- [ ] Authorization responses include iss and clients/tests validate it before code redemption.\n- [ ] Cross-issuer code/client credential substitution is rejected by behavioral negative tests.\n- [ ] CIMD is the preferred supported path; DCR remains a tested compatibility fallback.\n- [ ] Stored client identity is issuer-bound and cannot be replayed against another authorization server.\n- [ ] Enterprise-managed access, if enabled, remains user-attributed, tenant-scoped, revocable, and entitlement-gated.\n- [ ] Retryable entitlement-verification failures remain retryable rather than becoming terminal denials or cached grants.\n- [ ] OAuth metadata, public docs, error catalog, and MCP connection UI stay contract-consistent.\n- [ ] Focused OAuth/MCP security tests and npm run typecheck:api pass sequentially.\n\n## Non-goals\n\n- Changing published plan allowances without a separate product decision.\n- Removing DCR immediately.\n- Treating API key count as seat or organizational entitlement.
Contributor guide
Research direction
Start by reading the protocol and extension negotiation foundation in #5817, then inspect the listed OAuth surfaces and MCP entitlement/token storage paths. Trace issuer validation, CIMD/DCR handling, and enterprise entitlement checks before defining focused behavioral security tests. Done means issuer-bound credentials, CIMD preference with DCR fallback, fail-closed tenant access, consistent metadata and docs, and passing the focused tests plus npm run typecheck:api.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, authentication, authorization, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100