Is MCP a Security Nightmare?: A Look into MCP Authorization with OAuth2 (cefboud.com)

A recent analysis unpacks security trade-offs in the Model Context Protocol (MCP), which standardizes how LLMs plug into external tools so they can act on users’ behalf. The post warns that MCP’s convenience—letting any LLM discover and use services like GitHub, Slack, or Jira without custom integration—greatly expands the attack surface: prompt injection, malicious remote servers, or misuse of sampling capabilities can trick an LLM into executing harmful actions or exposing sensitive data. Notably, the MCP spec shifted between 2025-03-26 and 2025-06-18 from treating the MCP server as an OAuth Authorization Server to treating it as a Resource Server that relies on third-party Authorization Servers, a move meant to lean on the mature OAuth ecosystem but which also changes responsibility and threat models. Technically, MCP integrates OAuth2 (and OAuth 2.1 practices) using several RFCs: Authorization Server Metadata (RFC8414), Dynamic Client Registration (RFC7591), Protected Resource Metadata (RFC9728) and Resource Indicator (RFC8707). MCP servers can return a WWW-Authenticate header pointing clients to AS metadata, enabling dynamic discovery, on-the-fly client registration, and scoped tokens targeted at specific resource servers. That reduces manual setup and enforces least-privilege (via the resource field), but introduces risks like token misbinding between multiple RSs and transient client registrations. The takeaway: MCP brings powerful standardized agent capabilities, but only careful OAuth-based design, strict scope/resource binding, and rigorous endpoint vetting will prevent it becoming a security nightmare.