Feature Request: Authentication Support for MCP Server

[ferstar]

Summary

Request for authentication mechanisms to enable secure access to Nowledge Mem MCP server, especially when accessed over network.

Current Situation

The Nowledge Mem MCP server currently does not implement any authentication mechanism. While this is acceptable for localhost-only usage, it poses security risks when the service needs to be accessed over a network (even private networks like VPN/Tailscale).

From the MCP client logs, I can see authentication attempts are being made but failing:

"No token data found"
"SDK auth error: fg: HTTP 404: Invalid OAuth error response"

This indicates the client is looking for authentication, but the server hasn't implemented the corresponding endpoints.

Use Cases

1. Multi-device development: Securely access memories from different workstations on a private network (e.g., desktop + laptop)
2. Remote development: Use Nowledge Mem over VPN/Tailscale when working remotely with proper access control
3. Team collaboration: (Future) Share specific knowledge bases with team members securely

Security Risks

Without authentication, anyone with network access to the MCP server can:

• Read sensitive data: Personal memories, conversation histories, and insights
• Modify or delete data: Unauthorized tampering with knowledge base
• Privacy violations: Access to potentially confidential information stored in knowledge graphs

These risks are especially critical since Nowledge Mem is designed to store personal context and long-term memories from AI interactions.

Proposed Solution

Implement authentication following MCP security best practices:

Phase 1: API Key/Bearer Token Authentication (Recommended first step)

• Generate API keys through the Nowledge Mem UI
• Client includes token in headers: Authorization: Bearer <token>
• Support token rotation and revocation

Example MCP Client Configuration:

{
  "mcpServers": {
    "nowledge-mem": {
      "url": "http://192.168.1.100:14242/mcp",
      "type": "streamableHttp",
      "headers": {
        "APP": "Claude Code",
        "Authorization": "Bearer mem_sk_xxxxx..."
      }
    }
  }
}

Phase 2: OAuth 2.1 Support (For advanced use cases)

• Follow the MCP Authorization specification
• Enable integration with existing identity providers
• Support for enterprise SSO scenarios

Implementation Priority

P0 (Critical):

• API Key/Bearer Token authentication
• Basic token validation on all MCP endpoints

P1 (High):

• Token management UI (generate, revoke, rotate)
• Token expiration and refresh mechanisms

P2 (Medium):

• OAuth 2.1 support
• Per-token permission scopes (read-only, read-write)

Reference

• MCP Authorization Specification
• Securing MCP Servers - Best Practices
• MCP Authentication Guide

Willingness to Contribute

I'd be happy to help test this feature or contribute to the implementation if guidance is provided.

---

Environment:

• Nowledge Mem Version: 0.4.9
• MCP Client: Claude Code 2.0.36
• Network Setup: Private network (Tailscale VPN)

[ferstar]

Temporary Workaround: Using Caddy as Auth Proxy

While waiting for native authentication support, I'm currently using Caddy as a reverse proxy to add token-based authentication. This is a simple and reliable solution for protecting network-accessible MCP servers.

Caddy Configuration (Caddyfile)

# Listen on port 14243 (or your preferred port)
:14243 {
    # Token-based authentication
    @authorized {
        expression {query.token} == "mem_sk_GSCM_zf15cH20Hi-II4IqMDs1RThgG0BJbwdT-rFwO8" || {header.Authorization} == "Bearer mem_sk_GSCM_zf15cH20Hi-II4IqMDs1RThgG0BJbwdT-rFwO8"
    }
    
    # Proxy authenticated requests to Nowledge Mem
    handle @authorized {
        reverse_proxy localhost:14242 {
            # Preserve SSE for streamableHttp transport
            flush_interval -1
        }
    }
    
    # Reject unauthorized requests
    handle {
        respond "Unauthorized: Invalid or missing token" 401 {
            close
        }
    }
    
    # Optional: Enable access logs
    log {
        output file /var/log/caddy/nowledge-mem-proxy.log
        format console
    }
}

Usage

1. Start Caddy:

   caddy run --config Caddyfile
   # or run in background
   caddy start --config Caddyfile
   

2. MCP Client Configuration:

   {
     "mcpServers": {
       "nowledge-mem": {
         "url": "http://your-server:14243/mcp?token=mem_sk_GSCM_zf15cH20Hi-II4IqMDs1RThgG0BJbwdT-rFwO8",
         "type": "streamableHttp",
         "headers": {
           "APP": "Claude Code"
         }
       }
     }
   }
   

   Alternative (using Authorization header):

   {
     "mcpServers": {
       "nowledge-mem": {
         "url": "http://your-server:14243/mcp",
         "type": "streamableHttp",
         "headers": {
           "APP": "Claude Code",
           "Authorization": "Bearer mem_sk_GSCM_zf15cH20Hi-II4IqMDs1RThgG0BJbwdT-rFwO8"
         }
       }
     }
   }
   

Advantages

✅ Battle-tested: Caddy is a production-grade reverse proxy
✅ SSE Support: Native support for Server-Sent Events (required by MCP streamableHttp)
✅ Simple Config: Just a few lines of configuration
✅ HTTPS Ready: Can easily add TLS with Caddy's automatic HTTPS
✅ Performance: Much better than custom Python/Node.js proxies

Limitations

⚠️ Token Management: Token is hardcoded in config (need to restart Caddy to change)
⚠️ Single Token: All clients share the same token (no per-user authentication)
⚠️ No Rotation: Manual process to rotate tokens

---

This workaround has been tested and working with Claude Code 2.0.36 + Nowledge Mem 0.4.9 over Tailscale VPN. It provides basic security until native auth is implemented.

Security Note: Make sure to generate your own random token instead of using the example above!