2026년의 MCP 인증
Model Context Protocol (MCP)는 에이전트가 서버와 통신하는 방식을 변화시켰습니다. 처음에는 계산기와 같은 로컬 도구로 시작되었으나, 이제는 원격 서버에서 실행됩니다. 이러한 변화로 인해 인증이 필수 요건이 되었습니다.
MCP 서버에 OAuth를 추가하려 한다면, 끊임없이 변하는 목표에 대비해야 합니다. 사양(spec)은 몇 달마다 변경되며, 에이전트마다 서로 다른 규칙 버전을 사용합니다.
다음은 MCP 인증의 현재 상태입니다.
핵심적인 변화
여러분의 MCP 서버는 인가 서버(authorization server)가 아닙니다. 리소스 서버(resource server)입니다.
과거에는 사양이 서버에서 토큰과 로그인을 처리하도록 강제했습니다. 이로 인해 서버가 무거워지고 확장하기 어려워졌습니다. Aaron Parecki와 Christian Posta 같은 전문가들은 이 문제를 지적하며, MCP 서버는 토큰을 검증하기만 해야 한다고 주장했습니다.
오늘날 표준은 다음과 같은 흐름을 따릅니다:
• 인증되지 않은 요청은 401 에러를 받습니다. • 에러는 클라이언트에게 리소스 메타데이터를 찾을 위치를 알려줍니다. • 클라이언트는 적절한 인가 서버(Okta 또는 Keycloak 등)를 찾습니다. • 클라이언트는 토큰을 획득하여 MCP 서버에 제시합니다. • 서버는 토큰을 검증하고 도구를 실행합니다.
파편화 문제
표준이 존재함에도 불구하고, 에이전트마다 구현 방식이 다릅니다.
• Claude Desktop: 전체 OAuth 흐름을 실행합니다. • Claude API: 사용자 자신의 bearer token을 전달해야 합니다. • ChatGPT: 등록을 위해 CIMD를 사용하며 최신 사양을 지원합니다. • Gemini: Google Cloud IAM 및 API key를 사용합니다. • VS Code: GitHub 및 Entra 제공업체를 지원합니다.
이는 특정 에이전트를 위해 구축된 서버가 다른 에이전트에서는 작동하지 않을 수 있음을 의미합니다. 어떤 벤더는 전체 로그인 흐름을 요구하는 반면, 다른 벤더는 사용자가 직접 토큰을 관리하기를 기대할 수도 있습니다.
개발자를 위한 세 가지 교훈
리소스 서버(Resource Server) 모델을 목표로 하세요. ID 제공자(identity provider)가 되려고 하지 마세요. RFC 9728을 사용하여 메타데이터를 제공하고 audience를 검증하세요.
두 가지 방식을 모두 지원하세요. "bring your own token" 방식의 API 호출과 전체 OAuth 흐름을 모두 처리할 수 있도록 서버를 구축하세요.
지속적인 업데이트를 예상하세요. 사양은 여전히 진화 중입니다. OAuth 2.1은 아직 초안 단계이며, MCP 프로토콜도 아직 자리를 잡아가는 과정에 있습니다.
현재 MCP 서버를 구축하는 것은 어렵습니다. 규칙이 빠르게 변하기 때문입니다. 유연성을 유지하고 리소스 서버 모델을 고수한다면, 이러한 변화 속에서도 살아남을 수 있을 것입니다.
Optional learning community: https://t.me/GyaanSetuAi