MCP 인증 스펙 심층 리뷰 (2025-03-26 에디션)

MCP (모델 컨텍스트 프로토콜)은 AI 모델이 외부 도구와 서비스를 상호작용할 수 있게 하는 오픈 표준입니다. 이는 업계에서 널리 채택되었습니다. MCP가 HTTP 기반 전송 방법을 지원하므로 원격 MCP 서버는 MCP 생태계에서 점점 더 중요한 역할을 할 것입니다.

각 사용자가 각자 자신의 서버 인스턴스를 실행할 수 있는 로컬 MCP 서버와 달리, 원격 MCP 서버는 모든 사용자가 동일한 MCP 서버 서비스를 공유해야 합니다. 이는 MCP 인증 스펙이 해결하고자 하는 핵심 문제를 제기합니다: 사용자를 대신하여 MCP 서버가 사용자 리소스에 접근하도록 허용하는 방법.

이 글에서는 MCP 인증 스펙을 깊이 있게 분석할 것입니다. 이는 MCP 인증 스펙의 설계 원칙과 MCP 인증 구현을 위한 몇 가지 방향을 이해하는 데 도움을 줄 것입니다. 이 스펙은 여전히 발전 중이므로, 저는 Authenticator 구현에서의 개인 경험을 바탕으로 몇 가지 생각을 공유하겠습니다. 여기에는 다음이 포함됩니다:

• 인증 프레임워크로서의 OAuth 2.1의 장점과 한계
• 인증 서버이자 리소스 서버로서의 MCP 서버의 이중 역할의 도전
• 전체 인증 서버를 구현하는 실질적인 복잡성
• 위임된 제3자 인증에 적합한 시나리오 분석
• 동적 클라이언트 등록의 실질적 트레이드오프
• MCP 서버의 리소스 경계를 명확히 정의하는 것의 중요성

MCP 인증 스펙 개요#

MCP 인증 스펙은 MCP 서버 (원격)와 MCP 클라이언트 간의 인증 프로세스를 정의합니다.

OAuth 2.1에 기반을 두는 것이 매우 합리적인 선택이라고 생각합니다. OAuth는 인증 프로토콜 프레임워크로서, 사용자가 제3자 애플리케이션에 사용자를 대신하여 사용자 리소스에 접근하도록 허용하는 문제를 해결합니다. OAuth에 익숙하지 않다면 AuthWiki-OAuth에서 더 많은 정보를 확인할 수 있습니다.

MCP 클라이언트와 MCP 서버 시나리오에서는, "사용자가 MCP 클라이언트에 MCP 서버에서의 사용자 리소스에 접근하도록 허용하는 것"에 관한 것입니다. "MCP 서버에서의 사용자 리소스"는 현재 주로 MCP 서버가 제공하는 도구나 MCP 서버의 백엔드 서비스가 제공하는 리소스를 가리킵니다.

OAuth 2.1 인증 프로세스를 구현하기 위해, 프로토콜은 MCP 서버가 MCP 클라이언트와 협력하여 OAuth 2.1 인증 프로세스를 완료하기 위해 다음 인터페이스를 제공할 것을 요구합니다:

• /.well-known/oauth-authorization-server: OAuth 서버 메타 데이터
• /authorize: 인증 엔드포인트, 인증 요청에 사용
• /token: 토큰 엔드포인트, 토큰 교환 및 갱신에 사용
• /register: 클라이언트 등록 엔드포인트, 동적 클라이언트 등록에 사용

인증 프로세스는 다음과 같습니다:

스펙은 또한 MCP 서버가 제3자 인증 서버를 통한 위임된 인증을 지원하는 방법을 명시합니다.

스펙상의 예제 흐름은 다음과 같습니다 (스펙 내용에서):

이 시나리오에서, MCP 서버가 제3자 인증 서버에 인증을 위임하더라도, MCP 서버는 여전히 MCP 클라이언트를 위한 인증 서버로 역할합니다. 이는 MCP 서버가 MCP 클라이언트에 자체 액세스 토큰을 발급해야 하기 때문입니다.

제 관점에서, 이 시나리오는 MCP 서버가 MCP 클라이언트(사용자)를 대신하여 제3자 리소스(예: Github 레포지토리)에 접근해야 하는 상황을 처리하는 데 더 적합해 보입니다. 이 시나리오에서 MCP 서버는 인증 서버이며 리소스 서버로 역할합니다.

요약하자면, 프로토콜에 따르면, MCP 서버는 OAuth에서 인증 서버와 리소스 서버 역할을 모두 합니다.

다음으로, MCP 서버의 인증 서버 및 리소스 서버로서의 책임을 논의해보겠습니다.

MCP 서버로서의 인증 서비스#

MCP 서버가 인증 서버로 역할할 때, 이는 MCP 클라이언트의 최종 사용자가 MCP 서버에 자신의 식별자를 가지고 있음을 의미합니다. MCP 서버는 이 최종 사용자를 인증하고 MCP 서버 리소스에 접근하기 위한 액세스 토큰을 이 사용자에게 발급할 책임이 있습니다.

위에서 언급한 MCP 인증 스펙이 요구하는 인증 관련 인터페이스는 MCP 서버가 인증 서버의 구현을 제공해야 한다는 것을 의미합니다.

그러나 MCP 서버에서 인증 서버 기능을 구현하는 것은 개발자에게 상당한 도전입니다. 한편으론 대부분의 개발자가 OAuth 관련 개념에 익숙하지 않을 수 있습니다. 다른 한편으로는 인증 서버를 구현할 때 많은 세부 사항을 고려해야 합니다. 관련 분야의 개발자가 아니라면 구현 중 보안 문제와 같은 문제를 도입할 수 있습니다.

그러나 프로토콜 자체는 MCP 서버가 반드시 인증 서버 기능을 자체적으로 구현해야만 한다고 한정하지 않습니다. 개발자들은 충분히 이 인증 관련 엔드포인트를 다른 인증 서버로 리다이렉트하거나 프록시할 수 있습니다. 이는 MCP 서버가 인증 서버 기능을 자체적으로 구현하는 것과 MCP 클라이언트에 아무런 차이가 없습니다.

이 접근 방식이 이전에 언급한 위임된 제3자 인증 방법을 사용해야 하는지 궁금할 수도 있습니다.

제 관점에서는, 이는 주로 의존하는 제3자 인증 서비스의 사용자가 MCP 서버의 최종 사용자와 동일한지 여부에 달려있습니다. 이 말은 제3자 인증 서비스가 발급한 액세스 토큰이 MCP 서버에서 직접 소비된다는 것을 의미합니다.

• 그렇다면, MCP 서버의 Auth 관련 인터페이스를 제3자 인증 서비스로 충분히 포워딩할 수 있습니다.

• 그렇지 않다면, 스펙에서 규정한 위임된 제3자 인증 접근 방식을 사용해야 합니다. MCP 서버에서 자체적으로 발급한 액세스 토큰과 제3자 인증 서비스에서 발급한 액세스 토큰 간의 매핑 관계를 유지해야 합니다.

제 관점에서는, 프로토콜에서 지정한 위임된 제3자 인증 접근 방식이 실제 애플리케이션 시나리오에서 약간 모호하다고 생각합니다. 프로토콜은 제3자가 MCP 서버의 인증 프로세스를 돕는다고 해석할 수 있지만, 여전히 MCP 서버가 자체 액세스 토큰을 발급해야 한다는 책임을 지우고 있습니다. 이는 개발자에게 더 편리한 것이 아닙니다. 이는 아마도 프로토콜 작성자가 직접 MCP 클라이언트에 제3자 액세스 토큰을 반환하는 것이 일부 보안 문제(누출/남용 등)를 가져올 수 있다고 고려한 것일 수 있습니다.

제 경험으로는, 프로토콜에서 지정한 위임된 제3자 인증의 가장 적합한 시나리오는 "사용자가 MCP 서버에게 제3자 리소스에 접근할 수 있도록 허용하는" 시나리오여야 합니다. 예를 들어, MCP 서버가 사용자의 Github Repo에 접근하여 Repo의 코드를 코드 배포 플랫폼에 배포해야 하는 경우입니다. 이 경우, 사용자는 MCP 서버가 자신의 Github Repo에 접근할 수 있도록 허용해야 하며 코드 배포 플랫폼에 접근할 수 있도록 허용해야 합니다.

이 시나리오에서, MCP 서버는 MCP 클라이언트에 대해 인증 서버 역할을 합니다. 이는 최종 사용자가 MCP 서버에 자신의 식별자를 가지고 있기 때문입니다. MCP 서버는 제3자 리소스에 대해서는 제3자 클라이언트입니다 (이 경우 Github). 사용자 리소스에 접근하기 위해 사용자 인증을 받아야 합니다. MCP 클라이언트와 MCP 서버, MCP 서버와 제3자 리소스 사이에서는 사용자 식별자가 분리되어 있습니다. 이는 MCP 서버 자체가 발급한 액세스 토큰과 제3자 인증 서비스에서 발급한 액세스 토큰 간의 매핑 관계를 유지하는 것이 의미가 있습니다.

그래서 프로토콜에서의 위임된 제3자 인증 프로토콜은 "사용자가 제3자 리소스 서버에서 사용자 리소스를 액세스하기 위해 MCP 서버에 인증을 부여하는 방법"에 대한 문제를 해결해야 합니다.

리소스 서버로서의 MCP 서버#

MCP 서버가 리소스 서버로 역할할 때, MCP 서버는 MCP 클라이언트의 요청에 유효한 액세스 토큰이 있는지 여부를 검사해야합니다. MCP 서버는 액세스 토큰의 범위에 따라 MCP 클라이언트에 특정 리소스를 액세스할 수 있도록 허용할지 여부를 결정할 것입니다.

MCP의 정의에 따르면, MCP 서버가 제공하는 리소스는 MCP 클라이언트가 사용할 도구여야 합니다. 이 시나리오에서 MCP 서버는 사용자가 특정 도구에 접근할 수 있도록 제공할지 여부만 결정하면 됩니다.

그러나 실제 시나리오에서, MCP 서버가 제공하는 이러한 도구는 MCP 서버 서비스 제공자의 리소스 서버와 상호작용해야 합니다. 이때, 클라이언트 요청에서 얻은 MCP 서버의 액세스 토큰은 자체 리소스 서버에 액세스하는 데 사용해야 합니다. 대부분의 경우, MCP 서버와 도구 뒤에 있는 리소스 서버는 같은 개발자입니다. MCP 서버는 MCP 클라이언트가 사용할 수 있는 자체 백엔드 리소스를 제공하는 인터페이스 역할만 합니다. 이때, MCP 서버는 자체 측의 인증 서버가 발급한 액세스 토큰을 백엔드 리소스와 공유할 수 있습니다.

이는 오히려, MCP 서버가 리소스 서버로서 도구와 자체 서비스의 리소스를 제공하는 것보다, 기존 리소스 서버가 MCP 클라이언트가 호출할 수 있는 도구를 제공함으로써 MCP 서버로 되는 것이 더 적절합니다.

자체 리소스 서버가 제공하는 리소스를 MCP 서버가 제공하는 리소스에 포함시키는 것은 실제 시나리오를 고려한 것입니다. 그러나 개인적으로는 MCP 서버가 제공하는 리소스는 MCP 클라이언트가 사용하는 도구만 가지고 있고, 도구가 의존하는 리소스는 제1자 및 제3자를 포함하여 다른 리소스 서버에서 MCP 서버가 액세스해야 한다고 봅니다. 이렇게 하면 모든 실제 시나리오를 포괄할 수 있습니다.

MCP 인증의 작동 방법#

MCP 서버가 인증 서버와 리소스 서버로서의 책임을 이해한 후, MCP 인증이 어떻게 작동하는지 알 수 있습니다:

동적 클라이언트 등록#

스펙은 인증 서버가 클라이언트를 식별하는 방법도 정의합니다. OAuth 2.1은 동적 클라이언트 등록 프로토콜을 제공하여 MCP 클라이언트가 수동 사용자 개입 없이 자동으로 OAuth 클라이언트 ID를 얻을 수 있도록 합니다.

스펙에 따르면, MCP 서버는 OAuth 2.0의 동적 클라이언트 등록 프로토콜을 지원해야 합니다. 이렇게 하면 MCP 클라이언트가 새로운 서버에 자동으로 등록하여 OAuth 클라이언트 ID를 얻을 수 있습니다. MCP 시나리오에서 이 방법이 권장되는 이유는 다음과 같습니다:

• MCP 클라이언트가 사전에 모든 가능한 서버를 알 수 없습니다
• 수동 등록은 사용자에게 불편을 초래할 것입니다
• 새로운 서버와의 연결을 원활하게 만듭니다
• 서버가 자체 등록 정책을 구현할 수 있습니다

하지만 현실적인 관점에서 MCP 시나리오에서 동적 클라이언트 등록의 적용에 대한 몇 가지 생각이 있습니다:

• 실제 OAuth 서비스 실무에서는, 클라이언트가 통상적으로 특정 비즈니스 앱과 일대일로 대응합니다. 클라이언트를 동적으로 생성하는 것은 OAuth 서비스에서 관련 자원(사용자, 앱 등)을 효과적으로 관리하는 데 기여하지 않을 수 있습니다. OAuth 서비스 제공자는 일반적으로 연결된 클라이언트에 대한 명확한 통제를 희망하며, 모든 클라이언트가 아무 때나 클라이언트로 등록하도록 두고 싶지 않습니다.
• 많은 OAuth 서비스는 사용자가 동적으로 클라이언트를 생성하는 것을 권장하지 않거나 허용하지 않습니다. 이는 서비스 남용으로 이어질 수 있기 때문입니다. 대부분의 성숙한 OAuth 서비스 제공자(예: Github, Google 등)는 개발자 콘솔을 통해 클라이언트를 수동으로 등록하도록 요구하며, 애플리케이션, 콜백 URL 등의 자세한 정보를 제공해야 할 수도 있습니다.
• OAuth 클라이언트를 수동으로 등록하는 것은 실제로 개발 과정에서 한 번만 필요한 작업이며 모든 최종 사용자가 필요로 하는 일이 아닙니다. 이는 개발자에게 큰 부담을 주지 않을 것입니다.
• 퍼블릭 클라이언트(예: 네이티브 애플리케이션, 단일 페이지 애플리케이션 등)에는 동적 등록 없이 OAuth 흐름을 안전하게 구현할 수 있는 더 안전한 방법이 있습니다. 클라이언트 ID와 PKCE(코드 교환을 위한 증명 키)를 결합하여 퍼블릭 클라이언트에 대한 충분히 안전한 OAuth 흐름을 제공할 수 있습니다.
• 프로토콜은 동적 클라이언트 등록을 사용하는 것이 클라이언트가 사전에 클라이언트 ID를 알 필요를 회피할 수 있다고 언급하고 있지만, 사실 MCP 클라이언트는 항상 원격 MCP 서버의 주소를 사전에 알아야 합니다. 그렇다면 원격 MCP 서버 주소를 전달할 때 클라이언트 ID를 지정하는 것이 큰 추가적인 문제를 가져오지 않을 것입니다. 또는 MCP 클라이언트가 MCP 서버에 클라이언트 ID를 요청하는 컨벤션을 만들 수도 있습니다. 이는 어려운 일이 아닙니다.

동적 클라이언트 등록은 이론상 MCP 생태계에 유연성을 제공하지만, 실제 구현에서 우리는 정말로 이 동적 등록 메커니즘이 필요한지를 고려할 필요가 있습니다. 대부분의 서비스 제공자에게는 OAuth 클라이언트를 수동으로 만들고 관리하는 것이 더 통제 가능하고 안전한 방법일 수 있습니다.

요약#

이 기사는 MCP 인증 스펙의 설계 철학 및 구현 도전 과제를 깊이 분석했습니다. OAuth 2.1에 기반을 둔 인증 프레임워크로서, 이 스펙은 원격 MCP 서버가 사용자를 대신하여 사용자 리소스에 접근하는 주요 문제를 해결하는 것을 목표로 합니다.

MCP 서버의 인증 서버 및 리소스 서버로서의 이중 역할, 동적 클라이언트 등록 및 제3자 인증 위임과 같은 메커니즘의 장단점을 상세히 논의하여, 인증 구현에서의 개인 경험에서 생각과 제안을 제공합니다.

MCP 인증 스펙은 여전히 발전 중이라는 점을 주목할 가치가 있습니다. Logto 팀의 일원으로서, 우리는 이 스펙의 최신 발전 사항에 지속적으로 주의를 기울이고, AI 모델과 외부 서비스 간의 안전한 상호작용에 기여하기 위해 실무에서 우리의 구현 솔루션을 지속적으로 최적화할 것입니다.