Recommended hook/enforcement point for external (out-of-gateway) user authorization across all surfaces (MCP transport, tools/list, /rpc, /sse)?

[luisFilipePT]

Context

We are deploying ContextForge as an MCP gateway with this identity model:

• MCP client users are validated outside the gateway. They authenticate against our organization's IdP and call the gateway with an IdP-issued bearer token. These users are not provisioned in ContextForge — no user records, no CF-issued tokens.
• Internal users (admin, management, a REST provisioning service) do exist in ContextForge and use CF-issued tokens as usual.
• Authorization decisions are made by an external authz service that we call at request time.

The question

Which plugin hook is the supported place to make an external allow/deny decision, such that it covers all client-facing surfaces — the MCP transport (/servers/<uuid>/mcp, /mcp), including tools/list, as well as /rpc, /sse, and /message?

What we found so far

We could not find a single hook that covers everything, and each candidate has a gap:

1. http_pre_request fires on every surface and carries the path — but it cannot deny: both continue_processing=False and raise PluginViolationError are silently discarded.
2. http_auth_resolve_user can deny (raising PluginViolationError → 401) — but only in its "attached" invocation via the get_current_user route dependency, which the MCP transport never uses. The "detached" invocation from AuthContextMiddleware does fire on MCP requests, but its 401 is swallowed ("continuing as anonymous") unless the exception message exactly matches one of _HARD_DENY_DETAILS; additionally, the detached payload carries no request path.
3. http_auth_check_permission never fires on the MCP transport.
4. tool_pre_invoke blocks correctly on all surfaces — but only covers tools/call. There is no hook for tools/list, and no HTTP hook can see the JSON-RPC body to distinguish methods.

Questions for the maintainers

1. Is there a supported configuration or hook we missed for making an external authorization decision that also covers the MCP transport (including tools/list)?
2. Is http_pre_request being non-blocking intentional and stable, or would a PR making it honor continue_processing=False / violations be considered?

Environment: ContextForge v1.0.6, native (in-process) plugins, mode: sequential, on_error: fail.

Thanks for the help 👐🏼

[rakeshutekar]

Not a maintainer, but your reading of the hook surface matches what's actually in the framework, so I'll at least confirm the source side of it in case it saves you chasing a hook that isn't there.

The plugin framework defines six core hook points (ADR 016, HookType):

PROMPT_PRE_FETCH / PROMPT_POST_FETCH
TOOL_PRE_INVOKE  / TOOL_POST_INVOKE
RESOURCE_PRE_FETCH / RESOURCE_POST_FETCH

So there is genuinely no tools/list hook. The tool hooks are scoped to invocation (tools/call), which is exactly why tool_pre_invoke blocks a call but nothing filters or denies a listing. That's a real gap, not something you overlooked.

The HTTP level hooks you found (http_pre_request, http_auth_resolve_user, http_auth_check_permission) are the newer additions layered on top, and your notes on each one line up with their behaviour: http_pre_request observes every surface but isn't a deny point, http_auth_check_permission doesn't fire on the MCP transport, and the detached http_auth_resolve_user path swallows the 401 unless the message hits the hard deny set. So across the six core hooks plus those three, there isn't one that both sees the JSON-RPC method (to catch tools/list) and can deny on the MCP transport.

Worth noting: ADR 016's "future" section explicitly lists auth_pre_check / auth_post_check as planned auth-integration hooks that aren't implemented yet. That's basically the hook you're asking for, so the gap looks like a not-yet rather than a deliberate no.

The two questions that actually need a maintainer, since they're about intent rather than what the code does: (1) whether http_pre_request being non-blocking is intentional or just incomplete, and (2) whether there's a sanctioned pattern for gateway-external authz on the MCP transport that covers tools/list today. For an out-of-gateway authz model like yours, if none of the current hooks fit, the realistic options until an auth hook lands are an ASGI middleware in front of the gateway that parses the JSON-RPC body to gate tools/list and tools/call uniformly, or restricting tool exposure per virtual server so the visible set is already scoped, but a maintainer should confirm which of those they'd actually recommend.

[luisFilipePT]

Thanks for the reply @rakeshutekar! Let's see if a maintainer can weigh in as well. In particular, it would be great to know whether there's an expected timeframe for this to become available: "Auth Integration: auth_pre_check/auth_post_check for custom authentication"