https://eunus.dev/tags/authentication/Recent content in Authentication onHugo -- gohugo.ioThu, 02 Jul 2026 00:00:00 +0600https://eunus.dev/blog/model-context-protocol-series-2a-oauth-2.1-for-mcp-connecting-claude-to-your-real-users-with-openiddict/Thu, 02 Jul 2026 00:00:00 +0600https://eunus.dev/blog/model-context-protocol-series-2a-oauth-2.1-for-mcp-connecting-claude-to-your-real-users-with-openiddict/Series 1 ended with a working MCP server — but every tool call it made to the backend used a service account with admin access and no tenant context. Which means Claude could, in theory, pull data from any tenant in the system. No audit trail. No permission boundaries. Just a skeleton key with your API’s address on it. That’s not a security model. That’s a liability. This post replaces the service account with OAuth 2.https://eunus.dev/blog/model-context-protocol-series-2b-the-bridge-middleware-that-lets-claude-debug-and-fix-its-own-tools/Thu, 02 Jul 2026 00:00:00 +0600https://eunus.dev/blog/model-context-protocol-series-2b-the-bridge-middleware-that-lets-claude-debug-and-fix-its-own-tools/Series 2A wired up the full OAuth 2.1 stack: discovery endpoints, mock Dynamic Client Registration, JWT validation, bearer token forwarding. Every piece of it works — right up until Claude Code opens the browser to log in, and OpenIddict slams the door: error: invalid_request error_description: The specified 'redirect_uri' is not valid for this client application. This post is about the one component that fixes it — a single bridge middleware — and why it earns its own post: it is the piece nobody else builds, because almost everyone tests their MCP OAuth against a client that never triggers the problem.