EMA 준비성: 기업 관리형 권한 부여(Enterprise-Managed Authorization) 시대를 위한 준수 기준

2026-06-18, Model Context Protocol의 기업 관리형 권한 부여 (Enterprise-Managed Authorization, EMA) 확장 기능이 Stable (안정화) 단계에 진입했습니다. 이는 MCP 유지 관리자인 Paul Carleton이 MCP 블로그를 통해 발표했으며, 같은 날 Frederic Lardinois가 The New Stack을 통해 보도했습니다. EMA는 기업 사용자를 위한 앱별 OAuth 동의 화면을 대체합니다. 이는 WG(Working Group)에서 채택된 IETF 초안인 Identity Assertion JWT Authorization Grant (

그 경계야말로 바로 지금 준수 기준 (conformance baseline)이 유용한 이유입니다. EMA는 MCP 서버의 권한 부여 (authorization) 태세 위에 엔터프라이즈급 인증 (authentication)을 계층적으로 쌓는 방식이며, 이는 해당 태세가 이미 견고하다는 것을 전제로 합니다. 따라서 이 포스트는 체크리스트입니다. 여러분의 MCP 서버가 EMA 준비가 되었는지 확인하는 방법과, 출시 하루 만에 생태계가 처한 현재 상황을 스냅샷으로 제공하여 모든 이들(출시 파트너 포함)이 기준을 강화할 수 있는 공통된 참조점을 가질 수 있도록 합니다.

생태계 스냅샷, 2026-06-19

발표 후 24시간 이내에 여러 출시 커넥터(launch connectors)가 자신들의 MCP 권한 부여 서버 (authorization-server) 메타데이터를 업데이트했으며, 그중 3곳은 authorization_grant_profiles_supported에 새로운 urn:ietf:params:oauth:grant-profile:id-jag 값을 추가했습니다. 주의할 점은 이것이 권한 부여 유형 (grant_type)이 아니라 권한 부여 프로필 (grant profile) 식별자라는 것입니다. (EMA 흐름에서의 실제 OAuth 권한 부여 유형 (grant_types)은 ID-JAG를 발행하기 위해 requested_token_type=urn:ietf:params:oauth:token-type:id-jag와 함께 사용되는 urn:ietf:params:oauth:grant-type:token-exchange와, 이를 상환하기 위한 urn:ietf:params:oauth:grant-type:jwt-bearer입니다.)

그 후 저는 오픈 소스인 authgent MCP-OAuth 준수 스캐너를 사용하여 동일한 메타데이터를 스캔했습니다. 이 스캐너는 권한 부여 서버 메타데이터를 MCP 2025-11-25 권한 부여 명세(authorization spec)가 요구하는 RFC들(RFC 7591, 7636, 8414, 8707, 9728)과 대조하여 확인합니다. 스냅샷은 다음과 같습니다:

벤더 (Vendor)	EMA / ID-JAG 프로필 광고 여부?	PKCE 방식	RFC 8707 리소스 인디케이터 (resource indicators)
Asana	—	["plain", "S256"]	광고되지 않음
...

두 가지 패턴이 나타나는데, 이는 경계해야 할 대상이라기보다는 한 줄의 설정 수정으로 해결할 수 있는 사항들입니다.

두 가지 커넥터(Asana, Canva)는 여전히 S256과 함께 plain PKCE를 광고하고 있습니다. OAuth 2.1 (draft-ietf-oauth-v2-1, §4.1.2.3)은 plain 방식을 권장하지 않습니다. RFC 7636 §4.4.1에서는 이를 새로운 서버가 사용해서는 안 되는 과도기적 폴백(transitional fallback)으로만 유지하고 있습니다. MCP 2025-11-25 인증 사양은 S256을 사용하는 PKCE를 의무화합니다. PKCE 다운그레이드(PKCE-downgrade) 계열( OAuch에서 BCP_4_8로 분류되었으며, 2024년 Authentik 및 2026-05-31년 Better-Auth에 대한 CVE / GHSA 항목이 있음)이 바로 OAuth 2.1이 요구 사항을 강화한 이유입니다. code_challenge_methods_supported에서 plain을 제거함으로써 이 문제를 해결할 수 있습니다.

접근 가능한 커넥터 중 RFC 8707 리소스 인디케이터(resource indicators)를 광고하는 곳은 없습니다. 먼저 주의할 점이 있습니다. 스캐너는 광고된 AS 메타데이터를 읽는 것이지 런타임 동작을 읽는 것이 아닙니다. 즉, 서버가 resource_indicators_supported: true를 설정하지 않고도 /token 엔드포인트에서 resource 파라미터를 강제할 수 있으며, 이 차이는 중요합니다. 따라서 이를

이 두 가지는 EMA가 도입하는 기능이 아니며, 놀랍지도 않습니다. 이는 잘 알려진 '새로운 기능에 엔지니어링 관심이 집중되면 기본 사항은 후속 검토를 받는다'는 패턴이며, 바로 이러한 후속 검토야말로 안정화된 명세(spec)와 공유 체크리스트가 쉽게 만들어주는 것입니다.

EMA가 해결하는 것 (그리고 여러분에게 남겨두는 것)

EMA / ID-JAG는 실제 문제를 해결합니다. EMA 이전에는 엔터프라이즈 사용자가 MCP 서버 + 앱 조합마다 분기별로 '허용(Allow)'을 클릭해야 했습니다. 30개의 MCP 통합 기능을 가진 5만 명 규모의 회사라면, 이는 연간 백만 건에 달하는 동의 클릭이었습니다. EMA는 이를 IdP에서 단일 SSO로 통합하고, IdP의 거버넌스 평면(governance plane)에서 사용자가 어떤 MCP 서버에 연결을 시도할 수 있을지 결정합니다.

하지만 EMA가 OAuth 준수성을 대체하는 것은 아닙니다. ID-JAG 초안(draft-ietf-oauth-identity-assertion-authz-grant, rev -04, 2026-05-21; 작성자: Aaron Parecki, Karl McGuinness, Brian Campbell; 아직 RFC가 아님)은 IdP에서 리소스(resource)로의 단계에 대해 RFC 8693 (토큰 교환, token exchange)을 프로파일링하고, 리소스 AS 단계에 대해 RFC 7521/7523 (JWT bearer)을 프로파일링합니다. 이는 근본적인 OAuth 자세(posture)가 건전하다고 가정합니다. 따라서 아래의 기본 사항은 EMA를 활성화하는 데 자연스러운 보조 수단입니다.

자체 MCP 서버에서 확인할 것

MCP 서버를 운영한다면, 세 가지를 확인해야 합니다:

pip install authgent-server
authgent-server lint https://your-mcp.example.com

관련 스캐너 체크 ID는 다음과 같습니다:

• MCP-PKCE-001 (MCP 필수): PKCE 방식. 정확히 ["S256"]를 광고해야 합니다. code_challenge_methods_supported에서 plain을 제거하는 것은 한 줄의 설정 변경으로 가능합니다.
• MCP-AUD-001 (MCP 필수): RFC 8707. AS 메타데이터는 resource_indicators_supported: true를 설정해야 하며, /token 핸들러는 resource 파라미터를 강제해야 합니다.
• MCP-EMA-001..004 (이번 주 신규, 권고 단계 (advisory tier)): EMA / ID-JAG를 위한 네 가지 준비성 체크 항목입니다. AS가 id-jag 권한 부여 프로필 (grant profile)을 광고하는지, grant_types_supported에 jwt-bearer가 포함되어 있는지, 어설션 검증 (assertion verification)을 위해 jwks_uri에 접근 가능한지, 그리고 동일한 메타데이터가 plain PKCE를 함께 광고하는지를 나타냅니다. 권고 단계이므로, 이 체크 항목들은 서버의 등급 (letter grade)에 절대 영향을 미치지 않습니다. 이는 완전히 새로운 확장 기능에 대해 미리 준비하지 않았다는 이유로 불이익을 주지 않으면서 EMA 준비성을 보여주기 위함입니다.

전체 방법론, 심각도 단계 (severity tiers), 그리고 해결 가이드는 docs/methodology.md에 있습니다. 동일한 코드 경로가 CLI, GitHub Action, 그리고 호스팅된 스캐너 UI로 실행됩니다. 또한 이 스캐너는 datatracker의 IETF Internet-Draft draft-agnihotri-oauth-agent-impl-status-00으로 문서화되어 있습니다.

벤더와의 협업

벤더와의 협업

이 스냅샷은 점수판이 아닌 공유 참조 자료로 제작되었습니다. 위에 언급된 각 커넥터는 이번 주에 해당 벤더별 이메일을 받아 특정 발견 사항, 스캐너의 개선 힌트, 그리고 docs/disclosure-policy.md에 따라 등급이 게시되기까지 14일간의 기간을 갖게 됩니다. https://authgent.dev/registry/의 공개 레지스트리에서는 해당 커넥터들을 '벤더 통보됨 — 등급 게시 예정' 상태와 함께 벤더별 날짜를 보여주며, 이 기간이 만료될 때까지 유지됩니다. 그리고 가장 먼저 수정 사항이 반영되면 항목은 실시간(live) 상태로 업데이트됩니다. EMA 검사는 자문적(advisory)이기 때문에, EMA 준비성 발견 사항 중 어느 것도 등급을 변경시키지 않습니다.

엔터프라이즈 보안 팀을 위한 안내

만약 테넌트에 대해 EMA를 활성화하는 것을 고려하고 있다면: 활성화하세요. 어제보다 나은 것이기 때문입니다. 그런 다음 온보딩의 일환으로 인벤토리 내 MCP 서버들에 대해 위 스캔을 실행하십시오. EMA는 IdP가 방금 생성하는 토큰들을 각 서버가 어떻게 처리하는지(what each server does with the tokens)를 통제하는 것이 아니라, _누가 연결할 수 있는지(who connects)_를 관리하므로, 간단한 S256 및 8707 검사가 그림을 완성해 줄 것입니다.

더 읽어보기

• The New Stack — MCP gets its missing enterprise authorization layer (Frederic Lardinois, 2026-06-18)
• MCP Enterprise-Managed Authorization spec
• draft-ietf-oauth-identity-assertion-authz-grant (ID-JAG, IETF OAuth WG)
• authgent on GitHub (여기서 사용된 스캐너, Apache 2.0)
• authgent IETF Internet-Draft (draft-agnihotri-oauth-agent-impl-status-00)
• authgent disclosure policy

의견, 수정 사항 및 반론은 언제나 환영합니다. 해당 리포지토리의 이슈 트래커 (issue tracker)를 통해 의견을 남겨주세요.