하네스 안쪽: MCP의 OAuth 발급자 바인딩, 그리고 프로토콜 보안이 문자열 비교에 달린 이유

숫자 세 개부터 보자. 그다음 설명하겠다. 하나, OAuth 메타데이터 문서의 발급자 필드는 문자열 하나다. 둘, 이번 여름 Atlassian, Context7, Home Assistant가 각각 MCP 인가 메타데이터를 제공했는데 그 문자열이 실제로 문서를 가져온 URL과 일치하지 않았고, 엄격한 클라이언트는 연결을 거부했다. 셋, 지금 MCP 사양에 들어간 수정의 핵심은 사실 “문자열을 비교하고, 다르면 거부하라”다. 메커니즘은 그게 전부다. 그런데 이 단순한 검사가 막는 공격은 OAuth에서 가장 까다로운 축에 속하는 혼동 공격이며, MCP의 배포 방식은 그 공격을 구조적으로 더 위험하게 만든다.

이번 글은 하네스 안쪽을 보는 글이니 배관으로 들어가겠다. 발급자 바인딩 문제가 무엇인지, 어떤 흐름에 영향을 주는지, 그리고 2026년 7월 28일 사양 묶음이 MCP 클라이언트나 서버를 만드는 사람에게 무엇을 요구하는지 살펴본다. 같은 릴리스의 상태 비저장 전송 변경은 헤드라인을 가져갔지만, 인증 강화에는 SEP가 여섯 개나 들어갔는데도 거의 다뤄지지 않았다. 순서가 거꾸로다. 실제 자격증명을 가진 MCP 서버를 운영한다면, 혼란에 빠진 클라이언트가 엉뚱한 상대에게 토큰을 넘기지 않게 만드는 부분은 바로 여기다.

핵심 요점 - MCP는 전통적인 OAuth 구조를 뒤집는다. 하나의 클라이언트가 런타임에 발견된 여러 인가 서버와 통신한다. 바로 그 구조가 혼동 공격이 노리는 위상이다. - 2026년 7월 28일 사양 묶음에는 SEP 여섯 개가 들어갔다. 가장 중요한 둘은 SEP-2468(RFC 9207에 따라 인가 응답의 iss 매개변수 검증)과 SEP-2352(등록된 모든 클라이언트 자격증명을 그것을 발급한 발급자에 바인딩)다. - 이건 이론이 아니다. Atlassian과 Context7의 MCP 엔드포인트는 이번 여름 실제 환경에서 발급자가 맞지 않는 메타데이터를 제공했고, 엄격한 클라이언트를 깨뜨렸다. 사양이 이미 프로덕션에서 일어난 실패를 따라잡고 있다. - iss 검증은 현재 권고 사항이고 의무화되는 방향으로 간다. 지금 넣는 편이 맞다. 지원해야 하는 서버가 iss를 보내지 않는다면 대충 넘어갈 일이 아니라 거부 사유로 보자. - 이 패키지를 완전히 적용해도 클라이언트와 서버 사이 인증만 강해진다. 에이전트 신원, 요청별 인가, 위임 출처, 감사는 여전히 프로토콜 밖에 있고 구현자 책임이다.

무슨 일이 있었나

2026년 5월 21일 MCP 유지관리자들은 2026년 7월 28일 사양의 릴리스 후보를 확정했고, 최종 사양은 7월 28일 나왔다. SDK 유지관리자들은 그 뒤 10주 검증 기간을 진행 중이다. 논평 대부분은 상태 비저장 전환에 쏠렸다. 하지만 Tigera가 릴리스를 자세히 분석한 글을 보면 그 아래에는 OAuth 계층을 강화하는 Spec Enhancement Proposal 여섯 개가 있다.

정리 성격이 강한 SEP 세 개(2207, 2350, 2351)는 명확화에 가깝다. 하지만 인증 사양에서 명확화는 중요하다. SDK 두 개가 메타데이터 문서 위치를 다르게 이해하면 그건 각주가 아니라 상호운용 장애다. 그래도 하중을 받는 핵심 둘은 2468과 2352다. 둘 다 같은 질문을 다룬다. 클라이언트는 자신이 실제로 어느 서버와 이야기하고 있는지 어떻게 아는가?

MCP 2026년 7월 28일 사양 묶음에는 OAuth를 강화하는 SEP 여섯 개가 들어 있다. 발급자 검증(2468), 발급자에 묶인 자격증명(2352), 동적 클라이언트 등록의 클라이언트 유형 선언(837), 그리고 명시된 리프레시 토큰(2207), 권한 범위 누적(2350), 검색 동작(2351)이다. 근거는 Tigera 분석이다. 릴리스 후보는 5월 21일 확정됐고 최종 사양은 2026년 7월 28일 나왔다.

취약점 모델: 클라이언트 하나, 여러 발급자

전통적인 OAuth는 많은 클라이언트와 하나의 인가 서버를 가정한다. 수천 개 앱이 하나의 신원 제공자와 하나의 토큰 발급자를 본다. 클라이언트가 인가 응답을 잘못된 서버에서 온 것으로 착각하게 만드는 혼동 공격은 상대적으로 틈새 문제였다. 대부분의 클라이언트는 발급자 하나하고만 대화했기 때문이다.

MCP는 이 구조를 뒤집는다. 하나의 클라이언트, 즉 호스트 애플리케이션이 여러 MCP 서버와 통신한다. 각 서버 앞에는 서로 다른 인가 서버가 있을 수 있고, 그 서버는 런타임에 발견되며 동적 클라이언트 등록으로 즉석 등록되는 경우도 많다. 사양 작성자들도 직접 그렇게 설명한다. Tigera 글이 인용한 표현에 따르면 발급자 검증 SEP는 “MCP의 단일 클라이언트, 다중 서버 배포 패턴에서 더 빈번한 혼동 공격 계열”을 겨냥한다. 클라이언트 하나가 동시에 십여 개 인가 서버에 등록돼 있다면 공격자는 암호를 깰 필요가 없다. 응답을 엉뚱한 서버의 것으로 착각하게 만들면 된다.

형태는 이렇다. 에이전트 호스트가 정상 서버 A와 흐름을 진행하던 중 실제로는 공격자가 통제하는 서버 B에서 온 응답을 받는다. 발급자 검사가 없으면 클라이언트가 B를 상대로 교환을 완료해 인가 코드를 흘리거나, B가 만든 토큰을 받아 다음 단계에 제시할 수 있다. 전통적인 OAuth 문제를 고친 2021년 RFC 9207은 인가 응답에 명시적 iss 매개변수를 추가해 예상하지 않은 발급자에서 온 응답을 거부할 수 있게 했다. SEP-2468은 그 요구를 MCP로 가져온다. SEP-2352는 더 조용한 절반인 자격증명을 다룬다. 그전에는 클라이언트가 발급자 A에서 받은 클라이언트 ID를 들고 있다가, 리소스가 발급자 B로 이전됐을 때 A의 자격증명을 B에 제시할 수 있었다. 가끔 작동하기도 했다. 인증 시스템에서 “가끔 작동한다”는 건 원하는 특성이 아니다. 그래서 2352는 인가 서버별로 등록을 따로 보관하고 발급자 값에 묶으며, 이전 시 다시 등록하도록 요구한다.

이 계열을 처음 손보는 것도 아니다. 2025년 6월 18일 사양 개정에서는 리소스 지시자(RFC 8707)를 의무화해 토큰이 특정 서버 하나를 대상으로 발급되게 했고, MCP 인가 사양은 이미 다른 리소스를 위한 토큰을 받거나 하위 시스템으로 그대로 전달하는 것을 금지한다. 2026년 7월 28일 패키지는 같은 방향을 이어간다. 기본 신뢰를 줄이고 명시적 바인딩을 늘린다. 내가 쓴 MCP와 API 비교를 읽었다면 여기에는 그 글에서 설명한 유연성의 비용이 보인다. 런타임 검색 덕분에 MCP는 조합하기 쉬워졌고, 바로 그 유연성이 이런 신원 문제를 만들어낸다.

MCP의 단일 클라이언트·다중 서버 위상은 혼동 공격이 노리는 배포 패턴과 정확히 겹친다. 공격자는 암호를 깨지 않는다. 클라이언트가 응답이나 자격증명을 잘못된 인가 서버에 귀속하도록 만든다. SEP-2468은 RFC 9207의 iss 매개변수로 응답을 발급자에 묶고, SEP-2352는 등록된 자격증명을 발급 서버에 묶는다. 근거는 Tigera 분석과 RFC 9207이다.

사양이 프로덕션 실패를 따라잡고 있다

이게 추상적으로 들린다면 그렇지 않다. 발급자 문자열은 이번 여름 실제 MCP 배포에서 계속 문제를 일으켰고, 엄격한 클라이언트는 이미 그 오류에 걸리고 있다.

7월 opencode 사용자는 Atlassian의 Rovo MCP 서버 OAuth가 검색 단계에서 실패하는 문제를 발견했다. 보호 리소스 메타데이터는 테넌트별 인가 서버를 올바르게 광고했지만, 그 위치에서 제공된 메타데이터 문서의 발급자는 문서를 가져온 테넌트 경로가 아니라 공유 발급자인 https://auth.atlassian.com으로 선언돼 있었다. RFC 8414 3.3절은 issuer 값이 메타데이터를 가져오는 데 사용한 URL에서 .well-known 접미사를 뺀 값과 정확히 같아야 한다고 요구한다. opencode의 엄격한 검증은 올바르게 거부했고 로그인은 완전히 막혔다. 실제 엔드포인트에서 확인된 Atlassian 측 사양 준수 버그였다. 6월에는 Context7의 MCP 엔드포인트도 비슷한 버그를 겪었다. 광고된 인가 서버와 Clerk 하위 도메인의 메타데이터 발급자가 달랐고, 공식 MCP Go SDK가 흐름을 거부했다. Home Assistant의 메타데이터는 발급자 필드 자체를 생략했다. 또 다른 방식으로 MCP 클라이언트를 깨뜨렸다.

세 사례 모두 혼동 공격이 실제로 성공한 사건은 아니다. 상호운용 실패였다. 하지만 그게 바로 핵심이다. 공격자가 만든 가짜 서버를 막는 문자열 비교가 허술하게 구성된 정상 서버도 똑같이 막는다. 이제 생태계는 원래부터 잘못돼 있었지만 예전에는 넘어가던 메타데이터에 훨씬 덜 관대해질 것이다. WorkOS가 혼동 공격을 설명한 글은 운영 관점에서 좋은 지적을 한다. 많은 OAuth 라이브러리가 아직 RFC 9207 검사를 기본 비활성화하고 있으며, CVE-2026-59208을 예로 들어 계정 조회를 sub 값 전체에 전역 매칭하지 않고 확인된 발급자 범위로 제한했으면 버그를 완전히 막을 수 있었다고 설명한다. 나는 그 CVE 언급은 독립 검증된 사실이 아니라 WorkOS가 보고한 사례로 보겠다. 방어 원칙 자체는 어느 쪽이든 표준적인 모범 사례다.

이번 여름 실제 MCP 배포에서는 발급자 검증 실패가 이어졌다. Atlassian의 Rovo MCP 서버는 메타데이터의 발급자가 문서를 가져온 테넌트 URL과 일치하지 않았고(opencode 이슈 #39332), Context7 엔드포인트는 광고한 인가 서버와 메타데이터가 선언한 서버가 달랐으며(Context7 이슈 #2723), Home Assistant는 발급자 필드를 아예 생략했다. RFC 8414 3.3절은 발급자 값이 검색 URL과 정확히 일치하도록 요구하므로 엄격한 클라이언트가 세 사례 모두를 거부한 것은 올바른 동작이다.

구현자가 해야 할 일

MCP 클라이언트를 유지관리한다면 다음을 하자.

1. 지금부터 모든 인가 응답의 iss를 검증하자. 현재 흐름을 진행 중인 발급자와 다르면 거부하고, 서버가 RFC 9207 지원을 광고하면서 매개변수를 생략해도 거부하자. 사양은 향후 버전에서 누락된 iss를 거부하는 동작이 요구될 것이라고 명시하고 있다. 지금 만드는 것에서는 이미 의무라고 취급하는 편이 낫다.

2. 등록 상태를 인가 서버별로 분리하자. 모든 클라이언트 ID, 비밀값, 리프레시 토큰을 그것을 발급한 발급자 값에 묶어 저장한다. 리소스의 보호 리소스 메타데이터가 새 인가 서버를 가리키기 시작하면 재등록해야 한다. 예전 자격증명을 재사용하지 말자.

3. 동적 클라이언트 등록에서 application_type을 선언하자. SEP-837은 데스크톱이나 CLI 클라이언트가 기본값 web으로 처리돼 로컬호스트 리디렉션 URI 때문에 거부되는 오류 계열을 없앤다. 필드 하나로 실제 버그 계열 하나가 사라진다.

4. 계정 조회 범위를 발급자로 제한하자. sub 클레임은 실제로 검증한 발급자의 네임스페이스 안에서만 계정과 매칭돼야 한다. 전역 매칭은 하지 말자.

MCP 서버나 그 앞의 인가 서버를 운영한다면, 메타데이터의 issuer가 문서를 가져온 URL과 정확히 같게 만들어야 한다. 테넌트 경로까지 포함한다. RFC 9728에 따라 보호 리소스 메타데이터를 구현하고, 토큰이 실제로 자신의 리소스를 대상으로 발급됐는지도 계속 검증해야 한다. 그리고 늘어나는 MCP 서버 목록을 상대로 에이전트를 셀프 호스팅하고 있다면 함대 규모의 산수가 중요해진다. N개 에이전트 곱하기 M개 서버는 N 곱하기 M개의 발급자 바인딩 등록을 뜻한다. 에이전트 10개면 스프레드시트로 버틸 수 있다. 100개면 레지스트리가 필요하다. 사양은 레지스트리에 대해서는 아무 의견이 없다. 그 부분은 플랫폼 몫이다.

구현자는 인가 응답의 iss를 검증하고(불일치와, 지원이 예상되는 경우 누락도 거부), 자격증명을 발급자별로 분리 저장하며 이전 시 재등록하고, 동적 클라이언트 등록에서 application_type을 선언하고, 계정 조회를 검증된 발급자 범위로 제한해야 한다. 근거는 Tigera의 SEP 분석과 WorkOS의 혼동 공격 가이드다. 1등급 SDK는 사양의 10주 검증 기간 안에 지원을 내놓을 것으로 예상된다.

사양이 아직 답하지 않는 것

패키지를 다시 읽어보면 여섯 SEP가 공통적으로 무엇을 하는지 보인다. 하나의 OAuth 클라이언트와 하나의 인가 서버 사이 교환을 강화한다. 꼭 필요했던 일이다. 하지만 Tigera 분석이 직설적으로 말하듯 토큰이 인증하는 것은 에이전트가 아니라 클라이언트다. 하나의 호스트 뒤에 에이전트 200개가 있으면 모두 같은 클라이언트 신원을 공유한다. 발급자 바인딩은 그 클라이언트 뒤에 어떤 에이전트가 있고, 누구를 대신해, 무엇을 근거로 판단하는지 말해주지 않는다. 권한 범위는 입장권이지 요청별 정책이 아니다. 위임 체인(에이전트가 에이전트를 호출하고 다시 서버를 호출하는 구조)은 모든 홉에서 OAuth 규칙을 깨끗이 지키면서도 처음부터 끝까지 책임 주체가 불분명할 수 있다. 그리고 이 패키지는 그 어느 것도 기록하라고 요구하지 않는다. 프로토콜의 범위로 보면 올바른 선택이고, 기업 관점에서는 불완전한 답이다.

이 작업의 가치를 깎아내리려는 말은 아니다. 발급자 검증이 없는 MCP는 인증서 검사가 없는 HTTP에 가까웠고, 그 구멍은 이제 닫히고 있다. 하지만 남은 네 가지, 에이전트 신원, 요청별 인가, 위임 출처, 감사가 곧 거버넌스 계층이다. 사양을 기다린다고 저절로 생기지 않는다. 내가 고객과 에이전트 거버넌스를 다룰 때 보는 공백과 같다. 에이전트 주변 환경에서 강제하거나, 아무도 강제하지 않는 둘 중 하나다.

자주 묻는 질문

MCP OAuth 발급자 바인딩 문제란 무엇인가?

MCP 클라이언트는 런타임에 발견한 여러 인가 서버와 통신한다. 그래서 응답이나 자격증명을 잘못된 서버에 귀속하는 혼동 공격에 취약하다. 2026년 7월 28일 사양은 클라이언트가 인가 응답의 iss 매개변수를 검증하도록 하고(SEP-2468, RFC 9207 채택), 등록된 모든 자격증명을 발급자에 바인딩하도록 요구해(SEP-2352) 이 문제를 고친다.

MCP 자체의 취약점인가?

프로토콜의 배포 패턴 때문에 더 흔해진 취약점 계열이며, 이제 사양 수준에서 막히고 있다. 이번 여름 프로덕션에서 관찰된 실패(Atlassian, Context7, Home Assistant가 발급자가 맞지 않는 메타데이터를 제공한 사례)는 구현 버그였다. 하지만 검증하지 않는 모델이 얼마나 취약했는지 보여준다. 이제 엄격한 검증이 기준이다.

어떤 흐름이 영향을 받나?

하나보다 많은 인가 서버에 등록된 클라이언트의 인가 코드 흐름, 서버 간 동적 클라이언트 등록, 리소스가 인가 서버 사이를 이전한 뒤 자격증명을 사용하는 경우, .well-known 문서를 통한 메타데이터 검색이 영향을 받는다. 단일 서버 배포가 문제였던 것은 아니다. 에이전트가 만들어내는 다중 서버 위상이 위험의 근원이다.

언제 의무가 되나?

2026년 7월 28일 사양은 최종본이고, SDK 지원은 5월 릴리스 후보 확정 이후 10주 검증 기간 안에 들어오고 있다. 사양은 향후 버전에서 iss가 없는 응답을 거부하도록 요구할 것이라고 명시한다. 지금 만드는 모든 구현에서는 이미 의무라고 취급하는 게 맞다.

결론

OAuth 보안은 대체로 결과가 큰 지루한 문자열 비교다. MCP도 이제 그 사실과 정면으로 마주쳤다. 2026년 7월 28일 패키지는 5년 된 OAuth 수정책을 가져와, 단일 클라이언트·다중 서버라는 형태 때문에 그 수정이 급해진 프로토콜에 넣었다. 마침 실제 배포에서도 그 검사가 실패하기 시작한 시점이었다. SDK를 업데이트하고, iss를 검증하고, 등록을 발급자에 묶자. 그런 다음 사양이 답하지 않은 것이 오히려 맞았던 질문을 해야 한다. 당신이 발급한 토큰이 승인하지 않았을 도구 호출에 쓰였고, 이름도 모르는 에이전트가 그 토큰을 제시했다면 누가 잡아내며, 기록은 어디에 남는가? 그 답은 사양에서 나오지 않는다. 사양을 둘러싸고 만드는 하네스에서 나온다.

MCP 배포의 인증과 신원을 정리하고 있다면, 내가 고객과 자주 나누는 이야기다. 연락하기.

출처

• Tigera, “MCP 인증 강화: 새 OAuth SEP 여섯 개가 고치는 것과 여전히 못 고치는 것”: https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (게시 2026년 7월 28일, 확인 2026년 8월 29일)

• WorkOS, “OAuth 혼동 공격과 RFC 9207: 토큰 교환까지 이어지지 못했던 발급자 검사”: https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (게시 2026년 7월 20일, 확인 2026년 8월 29일)

• Model Context Protocol, 인가 사양: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (게시 2025년 11월 25일, 확인 2026년 8월 29일)

• RFC Editor, RFC 9207, “OAuth 2.0 인가 서버 발급자 식별”: https://www.rfc-editor.org/rfc/rfc9207.html (게시 2021년 12월 16일, 확인 2026년 8월 29일)

• opencode 저장소, 이슈 #39332, “MCP OAuth: Atlassian 인증 실패, RFC 8414 발급자 불일치”: https://github.com/anomalyco/opencode/issues/39332 (게시 2026년 7월 28일, 확인 2026년 8월 29일)

• Context7 저장소, 이슈 #2723, “MCP OAuth 엔드포인트의 OAuth 메타데이터 발급자 불일치”: https://github.com/upstash/context7/issues/2723 (게시 2026년 6월 5일, 확인 2026년 8월 29일)

• Home Assistant Core, 이슈 #147059, OAuth 메타데이터의 발급자 누락: https://github.com/home-assistant/core/issues/147059 (게시 2025년 6월 17일, 확인 2026년 8월 29일)

• modelcontextprotocol/modelcontextprotocol 저장소: https://github.com/modelcontextprotocol/modelcontextprotocol (확인 2026년 8월 29일)