From d1bf0ccce2df39e232347ed1d7ffd75c9ef349b3 Mon Sep 17 00:00:00 2001 From: rusackas Date: Sat, 29 Aug 2026 04:16:07 -0700 Subject: [PATCH] docs(mcp): note MCP_AUTH_FACTORY bypasses guest auth and the JWT-secret startup failure Addresses review feedback: a custom auth factory skips the guest-token verifier entirely, and leaving GUEST_TOKEN_JWT_SECRET at its default with guest auth enabled fails MCP startup rather than just being insecure. Co-Authored-By: Claude Opus 4.8 --- docs/admin_docs/configuration/mcp-server.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/admin_docs/configuration/mcp-server.mdx b/docs/admin_docs/configuration/mcp-server.mdx index 4ccfb911474..1bb9c0d9685 100644 --- a/docs/admin_docs/configuration/mcp-server.mdx +++ b/docs/admin_docs/configuration/mcp-server.mdx @@ -279,6 +279,7 @@ curl -X POST http://localhost:5008/mcp \ - A dedicated guest-token verifier validates the token against the same `GUEST_TOKEN_JWT_SECRET` / `GUEST_TOKEN_JWT_ALGO` / `GUEST_TOKEN_JWT_AUDIENCE` config used by embedded dashboards, replays the embedded structural checks, and enforces revocation (global version bumps and per-dashboard `guest_token_revoked_before` cutoffs). It runs *before* the JWT verifier described above, since guest tokens are signed with a different key/algorithm and would otherwise be rejected at the transport. - A verified guest resolves to a Superset guest user as the highest-priority identity, so it's never downgraded to API-key / `MCP_DEV_USERNAME` / dev-mode resolution. Data access is scoped by the same checks (dataset allowlist, dashboard access, row-level security) that apply to embedded dashboard views. - Guests are restricted to a default-deny allow-list, `MCP_GUEST_ALLOWED_TOOLS`, regardless of `MCP_RBAC_ENABLED`. Sensitive enumeration tools like `find_users` and `get_instance_info` are denied simply by being absent from the default list. +- Setting `MCP_AUTH_FACTORY` bypasses this whole path: a configured factory is tried first, and the default factory that wires up the guest-token verifier is never reached. If you rely on a custom auth factory (e.g. your own OIDC provider) alongside guest auth, that factory must verify guest tokens itself -- otherwise they're rejected regardless of `MCP_EMBEDDED_GUEST_AUTH_ENABLED`. ```python # superset_config.py @@ -301,7 +302,7 @@ MCP_GUEST_ALLOWED_TOOLS = { - Restart the MCP process after toggling `EMBEDDED_SUPERSET` or `MCP_EMBEDDED_GUEST_AUTH_ENABLED` -- guest auth is wired up once at startup. :::warning -`GUEST_TOKEN_JWT_SECRET` guards both the web embedding and MCP guest-auth surfaces. Never leave it at its insecure default in production -- anyone who knows the default can forge guest tokens accepted by either. +`GUEST_TOKEN_JWT_SECRET` guards both the web embedding and MCP guest-auth surfaces. With `MCP_EMBEDDED_GUEST_AUTH_ENABLED` on, leaving it at its insecure default isn't just a forgery risk -- the MCP server refuses to start (`MCPAuthConfigError`) until you set a real secret shared with the guest-token minting service. ::: ---