> Custom OAuth implementation with user registration/login
Please don't. At 2 minute glance you are allowing empty state (csrf) and bearer tokens in query string[0], not checking if token is expired or not[1], storing secrets in plain text / not salting[2], missing PKCE Validation, debug mode always on, redirect URL only checking if includes (127.0.0.1.evil.com works)[3] so much...
Please, please, please don't recommend this for any production usage.
It’s just an initial version and a boilerplate, so it’s waiting for PRs to make it production-ready.
Hope to see someone opens PRs to fix these issues and make it better.
leblancfg · 2d ago
I hate the idea of MCP servers being their own OAuth providers and IMO I wouldn't use this. MCP servers just shouldn't have to handle OAuth user management. The only reason PostgreSQL is needed here is to store OAuth tokens for its users. It works though ¯\_(ツ)_/¯
The draft spec[1] – soon to be published AFAICT – flips this on its head and says "no, the MCP server is an OAuth2 protected resource, just go and talk to this authorization server and I'll accept its tokens". The MCP server doesn't need to handle anything related to auth. That's much saner, and would recommend people build towards _that_ particular future in mind.
But also broadly speaking: I strongly believe the mental model needs to move to MCP servers are URLs. It should just be extra endpoints and controllers on top of your app. I don't want to `npm install mcp-your-app` or go through someone else's implementation, I want to hit `https://your.app.com/mcp` directly.
I guess it's fine having the separate infra for an MCP server used to connect to 3p services... but fingers crossed, your 3p services starts exposing MCP endpoints directly.
Just like any 3rd party server, it needs its own auth i think. like Sentry MCP. You want to track your own, authenticated servers on Sentry. So you need to auth with your own creds.
written-beyond · 2d ago
I think what you should be "Show HN:" is your GitHub username.
fka · 2d ago
Haha makes sense.
swyx · 2d ago
this is incredible work. thanks for working all this out.
is there a latency point to using cloudflare workers if you are jsut going to call back to a central db anyway?
Please don't. At 2 minute glance you are allowing empty state (csrf) and bearer tokens in query string[0], not checking if token is expired or not[1], storing secrets in plain text / not salting[2], missing PKCE Validation, debug mode always on, redirect URL only checking if includes (127.0.0.1.evil.com works)[3] so much...
Please, please, please don't recommend this for any production usage.
[0] https://github.com/f/mcp-cloudflare-boilerplate/blob/master/... [1] https://github.com/f/mcp-cloudflare-boilerplate/blob/master/... [2] https://github.com/f/mcp-cloudflare-boilerplate/blob/master/... [3] https://github.com/f/mcp-cloudflare-boilerplate/blob/master/...
It’s just an initial version and a boilerplate, so it’s waiting for PRs to make it production-ready.
Hope to see someone opens PRs to fix these issues and make it better.
The draft spec[1] – soon to be published AFAICT – flips this on its head and says "no, the MCP server is an OAuth2 protected resource, just go and talk to this authorization server and I'll accept its tokens". The MCP server doesn't need to handle anything related to auth. That's much saner, and would recommend people build towards _that_ particular future in mind.
But also broadly speaking: I strongly believe the mental model needs to move to MCP servers are URLs. It should just be extra endpoints and controllers on top of your app. I don't want to `npm install mcp-your-app` or go through someone else's implementation, I want to hit `https://your.app.com/mcp` directly.
I guess it's fine having the separate infra for an MCP server used to connect to 3p services... but fingers crossed, your 3p services starts exposing MCP endpoints directly.
edit: Add URL, fix words
1. https://modelcontextprotocol.io/specification/draft/basic/au...
is there a latency point to using cloudflare workers if you are jsut going to call back to a central db anyway?