Add bearer token/API key auth for MCP endpoints

[karthikchary2606]

Problem

MCP endpoints (/mcp/sse, /mcp/message) currently require OAuth2 interactive authentication, making them unsuitable for:

• Programmatic access (CI/CD, automation, webhooks)
• Service accounts & API keys
• Non-browser MCP clients (Claude Code, custom agents, monitoring tools)
• Enterprise LDAP/SAML deployments (see Discussion How can I use MCP server with ldap auth ? #1496)

Current Limitation

• Session IDs from SSE handshake are ephemeral and garbage-collected when the stream closes
• No HTTP-based alternative endpoint
• No bearer token support
• No API key support
• No service account authentication
• Blocks entire category of programmatic use cases

Requested Solution

Add Spring Security filter chain for /mcp/** endpoints that:

1. Accept Authorization: Bearer <token> header
2. Support static API keys or JWT tokens
3. Keep OAuth2 for main UI endpoints (backward compatible)
4. Enable LDAP/SAML integration via bearer tokens

Use Cases Enabled

• Claude MCP integration (Claude Code, Claude UI)
• CI/CD automation (Jenkins, GitHub Actions, GitLab CI)
• Monitoring agents (Prometheus exporters, custom collectors)
• Webhooks and event processors
• Service-to-service communication
• Enterprise LDAP/SAML with bearer token delegation

Implementation Details

• Location: kafka-ui-api/src/main/java/io/kafbat/ui/config/McpAuthSecurityConfig.java (new)
• Scope: MCP endpoints only (/mcp/**)
• Backward Compatibility: Full (OAuth2 remains default for UI)
• Effort: ~2-4 hours
• Example:

curl -H 'Authorization: Bearer your-api-key' https://kafka-ui/mcp/sse

Why This Matters

MCP (v1.3.0+) is a powerful feature, but without programmatic authentication, it's unusable for automation. Currently:

• Users must manually extract browser SESSION cookies (hack, not production-ready)
• Session IDs expire unpredictably (ephemeral architecture)
• Cannot integrate with Claude AI or other AI agents
• Blocks enterprise adoption (LDAP users especially)

References

• Discussion How can I use MCP server with ldap auth ? #1496: MCP with LDAP Authentication (unanswered since Jan 31, 2026)
• Kafbat UI v1.3.0+: MCP implementation (authentication gap)

Community Impact

This would:

• ✓ Enable Claude MCP integration for Kafbat users
• ✓ Solve Discussion How can I use MCP server with ldap auth ? #1496 (LDAP + MCP)
• ✓ Complete the MCP feature (currently incomplete)
• ✓ Benefit the entire Kafbat community

[github-actions]

Hi karthikchary2606! 👋

Welcome, and thank you for opening your first issue in the repo!

Please wait for triaging by our maintainers.

As development is carried out in our spare time, you can support us by sponsoring our activities or even funding the development of specific issues.
Sponsorship link

If you plan to raise a PR for this issue, please take a look at our contributing guide.

[kapybro]

AI Summary

The issue requests adding bearer token or API key authentication for MCP endpoints (/mcp/sse, /mcp/message), which currently only support OAuth2, blocking programmatic access for CI/CD, service accounts, and non-browser clients. The proposed solution involves creating a Spring Security filter chain for /mcp/** endpoints to accept Authorization: Bearer <token> headers, supporting static API keys or JWT tokens while maintaining OAuth2 for UI endpoints. This would enable automation, enterprise LDAP/SAML integration, and AI agent (e.g., Claude) use cases, addressing a critical gap in MCP functionality.

[karthikchary2606]

Update: found a working interim client-side workaround using mcp-remote, documented in this project's own FAQ (https://ui.docs.kafbat.io/faq/mcp) as the recommended integration path for MCP clients without native remote-MCP support.

What doesn't work: mcp-remote's own automatic OAuth flow. It tries to discover MCP-spec OAuth server metadata against the MCP endpoint, finds none, then hits the raw /mcp/sse endpoint and gets a 302 to /oauth2/authorization/okta (i.e. the app's normal Spring Security/OIDC login redirect) instead of an SSE stream — so it can't complete auth on its own for a session-based OIDC login.

What does work: manually authenticating in a browser, extracting the resulting SESSION cookie, and passing it to mcp-remote via --header:

npx -y mcp-remote https://<kafka-ui-host>/mcp/sse --transport sse-only --header "Cookie:SESSION=<value>"

With a valid cookie, curl -H "Cookie: SESSION=<value>" .../mcp/sse returns 200 text/event-stream (the endpoint itself is healthy), and mcp-remote successfully connects and sustains the SSE stream (Connected to remote server using SSEClientTransport) — where a client's native/raw SSE transport (e.g. Claude Code's) previously failed. So the earlier assumption that the session couldn't be sustained by any client-side approach wasn't quite right — it was specifically the client's own SSE transport implementation, not something inherent to the server's session handling.

This unblocks interactive use today, but it's still not a fix for the underlying ask here: the cookie is tied to the live OIDC session (no fixed expiry, just goes stale on logout/idle/re-auth), so it requires manual browser re-auth + cookie extraction to refresh, and it's a non-starter for CI/CD, service accounts, or any unattended agent. Bearer token / API key support on /mcp/** (as originally requested) remains the durable fix for those cases.

Happy to share more detail on the discovery/redirect behavior if useful for scoping the implementation.

[karthikchary2606]

Additional findings from further testing today (via the mcp-remote + session-cookie workaround described above), on top of the auth gap: several MCP tools appear to be broken independent of authentication.

1. getClusters / getBrokers return a placeholder instead of real data

Calling getClusters (no args) returns:

{"scanAvailable":true,"prefetch":-1}

Calling getBrokers with clusterName: "staging" returns the exact same payload:

{"scanAvailable":true,"prefetch":-1}

For comparison, the equivalent REST endpoints (GET /api/clusters, GET /api/clusters/staging/brokers) using the same session cookie return correct data instantly (cluster list with broker counts/topic counts, full broker list with partition/ISR stats). So this isn't an auth or data-availability issue — the MCP tool handlers for these two endpoints appear to be wired to the wrong backend action (something scan/search-related) rather than the actual cluster/broker listing logic.

2. getBrokersCsv hangs indefinitely

Calling getBrokersCsv with clusterName: "staging" never returned a response — had to be manually cancelled after 30+ minutes. No timeout, no error, no partial output. The equivalent REST data is small (15 brokers) and returns in under 2 seconds via curl, so this isn't a backend/cluster performance problem — it's specific to this MCP tool's implementation (possibly a broken CSV-streaming code path that never terminates).

Net effect: beyond the missing bearer-token auth, at least two categories of MCP tool bugs exist independent of auth — (a) tools returning generic scan-status placeholders instead of real data, and (b) tools hanging indefinitely with no timeout. Given both patterns, I'd treat the MCP tool surface as largely unverified/unreliable right now beyond the initialize/connection handshake. Happy to help test further or provide repro steps against a Kafbat-hosted instance if useful.

[karthikchary2606]

Thanks for the detailed proposal! This Spring Security filter chain approach is
exactly what we need. A few clarifications before we proceed:

Questions

1. Token validation preference — For the initial implementation, would you prefer:

   • Static API key (simpler, recommended for service accounts)?
   • JWT support (more enterprise-friendly, allows token freshness)?
   • Both (configurable via properties)?

2. Configuration approach — Will this be:

   • Spring properties (mcp.auth.enabled, mcp.auth.token, etc.)?
   • Environment variables?
   • Both?

3. Timeline — Do you have availability to work on this, or would a PR contribution
   from the community be helpful?

4. Access scope — Will the bearer token endpoint maintain read-only access to
   cluster metadata? (We require read-only for AI agent integrations.)

Context

We're running Kafka UI in production at Pluralsight with Claude Enterprise access,
and we need programmatic MCP access for AI-driven troubleshooting and analysis.
We've already validated the workaround (SESSION cookie + mcp-remote proxy) and
confirmed the infrastructure is solid — this is purely an authentication gap.

Offer to Help

We're happy to:

• Test/validate the implementation in staging
• Write integration tests for bearer token flows
• Review the PR if you'd like feedback
• Document the MCP auth setup in your docs

Side Note

While we're at it, we noticed two additional issues affecting MCP reliability:

• getClusters/getBrokers return placeholder data {"scanAvailable":true,"prefetch":-1}
• getBrokersCsv hangs indefinitely with no timeout