xxx
Authentication
MCP does not currently define a standard authentication mechanism for how clients authenticate with servers, nor does it provide a framework for how MCP servers should securely manage and delegate authentication when interacting with third-party APIs. Authentication is currently left up to individual implementations and deployment scenarios. In practice, MCP’s adoption so far seems to be on local integrations where explicit authentication isn’t always needed.
A better authentication paradigm could be one of the big unlocks when it comes to remote MCP adoption. From a developer’s perspective, a unified approach should cover:
Client authentication: standards methods like OAuth or API tokens for client-server interactions
Tool authentication: helper functions or wrappers for authenticating with third-party APIs
Multi-user authentication: tenant-aware authentication for enterprise deployments
Authorization
Even if a tool is authenticated, who should be allowed to use it and how granular should their permissions be? MCP lacks a built-in permissions model, so access control is at the session level — meaning a tool is either accessible or completely restricted. While future authorization mechanisms could shape finer-grained controls, the current approach relies on OAuth 2.1-based authorization flows that grant session-wide access once authenticated. This creates additional complexity as more agents and tools are introduced — each agent typically requires its own session with unique authorization credentials, leading to a growing web of session-based access management.
From: A Deep Dive Into MCP and the Future of AI Tooling | Andreessen Horowitz.
xxx