MCP용 Zero-Touch OAuth

흔한 “MCP는 죽었고 Skills가 미래” 논쟁으로 가기 전에, MCP가 skills/CLI보다 실제로 가치 있는 지점은 인증 흐름을 에이전트의 컨텍스트 창 밖으로, 경우에 따라 하니스 밖으로까지 분리한다는 데 있음
보안 관점에서도 당연히 중요하고, 일반 사용자나 대기업이 AI 도구를 도입할 때 훨씬 쉬운 사용자 경험이 됨
컨텍스트 비대화나 도구 호출 중복에 대한 불만은 이해하지만, 인증을 이렇게 다루는 구조에는 분명한 가치가 있음
이상적인 MCP는 API 앞단의 인증 게이트웨이만 해도 충분히 이득일 수 있음

이 확장은 skills 대비 MCP의 다른 장점도 잘 보여줌: 중앙 통제, 직원 입장에서의 사용 편의성, 감사/컴플라이언스, 배포 모델
지금 skills 배포의 최선은 “이 파일을 복사해서 여기에 넣기”, “이 저장소를 체크아웃하고 심볼릭 링크 추가”, “슬래시 명령으로 설치” 정도로 보임
단순하긴 해도, 새 MCP 서버를 직원에게 배포하는 이 확장 방식만큼 쉽지는 않음

MCP는 훌륭한 감사 추적도 가능하게 해줌
예를 들어 6개 고객사의 Linear 계정 6개를 인증해두고, 어떤 계정을 쓸지 결정론적이고 감사 가능한 방식으로 선택하는 식의 책임 분리도 가능함

MCP 대 skills는 이분법이 아니라는 게 진짜 교훈임
둘은 그냥 서로 다른 도구이고, 요구사항에 따라 어느 쪽이 더 나을 수도 있고 아닐 수도 있음
칼과 톱 중 뭐가 더 낫냐는 질문과 비슷함

그 외에도 MCP는 런타임 환경 없이 외부 플랫폼을 연결할 수 있게 해줌
이 주제가 나올 때마다 엔지니어들은 Claude Code만 AI 에이전트의 유일한 앱인 것처럼 다루지만, 코딩 외 여러 업종에도 수많은 사용 사례가 있음
하니스가 로컬 머신이 아니라 클라우드의 격리되고 제한된 컨테이너에서 돌고, 임의 코드 실행은 절대 안 되는 환경일 수 있음
그래도 고객이 기존 도구를 에이전트에 연결하길 원할 때 MCP는 내장 인증이 있는 커넥터를 제공하므로 딱 맞고, skills는 이 영역에 해당하지 않음

친구들과 식당 리뷰를 하는 플랫폼을 만들고 있는데, 몇 번 시행착오 끝에 MCP가 맞는 방향으로 보임
일반 사용자는 Claude 디렉터리를 찾아 skill 파일을 붙여넣지 않음
“Connections”는 이해하기 쉽고, MCP를 붙여넣거나 마켓플레이스에서 찾는 편이 더 쉬움
장소와 리뷰에 에이전트가 접근하는 게 실제로 유용할지는 아직 미정임

Okta, Anthropic, Microsoft, Figma, Linear 등에서 이 작업을 만든 사람들에게 큰 축하를 보냄
MCP 회의론자들에게도 쓸 만한 게 있음
이건 ID-JAG라는 새 토큰 형식으로 동작하며, https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-a...에 있음
MCP 전용이 전혀 아니고, 같은 SSO 제공자를 쓰는 애플리케이션 사이에서 데이터를 안전하게 공유해야 하는 곳이라면 어디든 ID-JAG를 쓸 수 있음

이런 회사들 때문에 소프트웨어와 삶의 질이 더 나빠졌으니, 정말 축하할 일이라는 냉소가 듦

지금 구현 중인 MCP 서버에 Microsoft Entra ID 인증을 붙이려는데, 솔직히 내가 바보가 된 느낌임 WWW-Authenticate 헤더로 클라이언트에 리소스 메타데이터 URL을 알려줄 수 있고, 이를 통해 인증 서버인 Microsoft Entra와 앱 등록 범위도 지정할 수 있음
그런데 client_id는 지정할 수 없고, 그건 각 클라이언트, 즉 에이전트가 알아서 만든다는 식임
Microsoft Entra의 .../authorize URL로 로그인을 시작하려면 Entra의 앱 등록과 일치하는 알려진 client_id가 필요한데, 클라이언트가 임의로 만든 값이 Entra에 맞을 리 없음
이론상 동적 클라이언트 등록을 지원할 수는 있지만 Microsoft Entra는 당연히 지원하지 않음
결국 Microsoft Entra 앞에 자체 동적 클라이언트 등록 shim을 만들어 모두에게 같은 정적 client_id를 돌려주는 방법밖에 안 보임
이 프로토콜이 실제 엔터프라이즈에서 우회 없이 동작하는 게 맞는지, 내가 뻔한 걸 놓친 것 같은 느낌임

뻔한 걸 놓친 건 아닌 듯함
Entra ID는 동적 클라이언트 등록을 지원하지 않고, 이 생태계 상태는 아직 좋지 않음
보통 MCP OAuth는 사전에 등록된 전통적인 클라이언트로 처리하지만, 실제로 많은 MCP 클라이언트는 동적 클라이언트 등록이 된다고 가정하고 client_id를 지정하는 옵션을 제공하지 않음
다만 일부 클라이언트는 이를 지원하고, 광고를 겸하자면 우리 도구 Erato도 지원함: https://erato.chat/docs
엔터프라이즈에서 배포되는 일반적인 솔루션도 보통 웹 UI를 통해 MCP 접근을 중앙화하므로 이를 지원함
다른 대안으로는 MCP 게이트웨이가 있고, 게이트웨이와 서비스 사이에는 사전 등록 OAuth를 쓰고 게이트웨이와 클라이언트 사이에는 동적 클라이언트 등록을 허용할 수 있음

우리도 client_id 때문에 같은 문제를 겪었고, 보안상 동적 클라이언트 등록을 켜고 싶지 않았음
결국 앱이 OAuth 흐름을 프록시하면서 하드코딩된 client_id를 주입하게 만들었음
MCP 클라이언트에게는 동적 클라이언트 등록을 지원한다고 속이지만, 내부에서는 MCP용 독립 client_id를 평소처럼 쓰는 구조임
예시는 여기 있음: https://gist.github.com/erebe/a5de36d42214721b2466fb0e66f61c...

Anthropic에서 Okta와 여러 MCP 파트너와 함께 이걸 만든 사람 중 하나임
Claude에서 이 형태가 잡혀가는 게 매우 기대되고, MCP 명세에서도 EMA가 안정 확장이 된 만큼 다른 ID 제공자와 클라이언트로도 채택을 넓히고 싶음
피드백이 있으면 여기 남겨주면 좋겠고, 실제 사용 경험과 개선할 방법을 언제나 듣고 싶음

오랜만임
한동안 MCP를 안 봤는데, 이건 조직에서 MCP를 더 안전하게 만들고 동적 클라이언트 등록의 약점을 해결하는 데 꽤 잘 맞는 듯함
이제 클라이언트와 승인된 리디렉션 URI를 ID 제공자와 조직이 직접 설정할 수 있으니, 혼동된 대리자 공격이나 피싱 같은 DCR 기반 공격을 더 넓게 완화할 수 있음
또 ID 제공자나 조직이 DCR을 지원하지 않던 경우 MCP 서버가 구현해야 했던 인가 로직도 줄어들어 큰 장점이 됨
단점은 소비자 사용에는 여전히 DCR이 필요한 것처럼 보인다는 점임
GitHub, GitLab, Google 같은 소비자 OAuth 제공자가 정적 MCP 클라이언트/서버 등록을 지원하고, 클라이언트가 정적 client_id를 내장하고, 사용자가 해당 ID 제공자로 로그인해 연결을 직접 관리하게 하면 해결 가능할 수도 있음
전반적으로 XAA/EMA는 보안과 사용성 측면에서 DCR보다 훨씬 우월해 보임
우려되는 부분도 DCR보다 훨씬 해결하기 쉽고 보안 영향이 작음. 공격자가 자기 클라이언트를 등록할 수 없고 MCP 서버 개발자가 빠질 함정도 줄어들기 때문임

일반적인 “앱”에는 훌륭하지만, 우리에게는 사용자가 MCP를 설정하지 않고도 더 낮은 마찰로 에이전트 방식으로 상호작용할 방법이 절실함
일종의 임시 세션이나 대역 외 토큰 저장소가 있으면 좋겠음
사용 사례는 영업 과정에서 구매자와 판매자가 많은 정보를 교환하고 분석해야 하는데, 이 분석이 점점 에이전트식이 되고 있다는 것임
MCP의 문제는 초기 설정 마찰이 사용자가 직접 로그인해서 필요한 정보를 가져오는 것보다 훨씬 크다는 점임
MCP는 규칙적이고 빈번한 상호작용에는 좋지만, 빠른 일회성 세션에는 문제가 많음
Claude에서 “X, Y, Z에서 문서를 가져와”라고 하면 Claude가 해당 웹사이트에 접근하고, 사이트는 기본 사용 정보와 사용자가 브라우저에서 열 수 있는 로그인 링크를 돌려줌
사용자가 브라우저에서 인증하고, 콜백이 고유하고 짧게 사는 일회성 토큰을 돌려주며, 이후 사이트 요청에서 이를 교환하는 방식이면 좋겠음
이렇게 하면 사용자를 빠르게 인증하면서 작업 중 세션 상태도 유지할 수 있음

Microsoft Entra, 즉 Azure AD 팀과 소통이 있는지 궁금함
곧 기대해도 되는지, 아니면 시간이 꽤 걸릴지 알고 싶음

이건 정말 훌륭함
지난 몇 달간 MCP 쪽 사람들과 몇 가지 SEP와 Go 실험용 SDK를 함께 다룰 수 있어 운이 좋았음
예전에는 “그냥 API잖아”, “또 추상화를 하나 만들었네”라고 하던 회의론자였음
사람들이 놓치는 건 MCP의 “P”가 오해를 만든다는 점임
전통적인 앱을 만들 때는 폼, UI, 요청/응답 처리, 양방향 채널, 장시간 작업, 인증 등을 만들어야 함
MCP를 쓰면 이 공통 계층의 80%가 처리되므로, MCP는 프로토콜이기도 하지만 사실상 앱 프레임워크에 가까움
통합 인증은 엄청난 강화이고, 앞으로 더 멋진 것들이 기대됨

내가 만든 작업이 밖에서 보이는 건 꽤 신기함
Atlassian에서 이 흐름의 RAS 쪽 구현을 맡았음
CIMD, 더 나은 테넌시 지원 등 이 흐름에는 분명 반복 개선이 있을 것임
Anthropic, Okta, Atlassian에서 이걸 전달한 사람들은 모두 훌륭했음

웹을 지원해서 그냥 장기 쿠키를 발급할 수 있게 해주면 좋겠음
OAuth 서버 없이 이걸 하려고 OAuth 핸드셰이크로 쿠키를 통과시키도록 명세를 해킹했음
이런 걸 허용하지 않으려는 건 정말 답답함
쿠키가 없으면 웹페이지를 열고, 쿠키가 설정되면 닫고 저장하면 됨
MCP에 대해 80쪽짜리 미니북까지 썼지만, 여전히 끝없이 답답함

MCP 프로젝트의 리드 메인테이너 중 한 명인데, 이 방식은 여러 시나리오에서 확장되지 않음
사용성과 보안 양쪽 모두에서 문제가 있고, 쿠키는 브라우저를 위해 만들어진 것임
MCP 서버와 클라이언트는 브라우저가 보장되지 않는 환경에서 동작하는 경우가 많음

그건 그냥 자격 증명을 도난당하게 해달라는 것에 가까움 장기 자격 증명은 큰 책임 부담임

여러 번 읽어봤는데 확실히 유용함
감사와 접근 제어를 ID 제공자 한곳에 중앙화하고, 필요할 때 토큰 교환을 맡는 프록시 API 게이트웨이처럼 ID 제공자가 동작할 수도 있음
이 분야의 다른 플레이어들도 채택한 접근임
개인적으로는 ID 제공자가 내가 인지하지 못한 상태에서 내 권한을 클라이언트에 위임한다는 점이 조금 불편함
브라우저에서 사용자가 존재하는 흐름에 너무 익숙해서 그런지도 모르겠고, 점점 머신을 위한 접근 중앙화로 진화하는 느낌임
엔터프라이즈 환경에서는 신원이 개인보다 회사에 속하므로 받아들일 만할 수 있음
하지만 고객 ID 쪽에 통합하는 건 전혀 다른 난제이고, ID 제공자·클라이언트·리소스 인가 서버 사이에 이런 신뢰를 만들기는 아마 쉽지 않음

이 통합이 소비자 영역에서 동작하지 못하게 하는 이론적 장벽은 없음
예를 들어 GitHub에 로그인되어 있으면 Sentry에도 자동 로그인되게 하는 식의 신뢰 관계를 만들면 됨
앞으로 할 일이 더 많지만, 현재 가장 명확한 사용 사례는 말한 대로 엔터프라이즈임
관리자는 개별 직원이 여기저기 클릭하면서 임의의 자격 증명을 고르게 하고 싶어 하지 않음

C1에서는 내부 MCP 사용과 제품 내 MCP Gateway 양쪽에서 MCP 인증이 큰 골칫거리였기 때문에, 이게 들어오는 게 매우 반가움
오늘 C1이 EMA ID 제공자로 동작하는 지원을 출시했고, 짧게 사는 범위 제한 토큰을 발급함
이제 Linear와 우리가 쓰는 다른 MCP들에 연결해 반복적인 OAuth 흐름에서 벗어나고 싶음
Claude는 내장 커넥터 일부, 적어도 Slack에서는 이런 걸 마법처럼 해왔고 경험이 꽤 좋음
공개하자면 C1의 VPE이고, 깊게 파고드는 사람을 위해 접근 방식을 문서화해 두었음: https://www.c1.ai/docs/product/admin/enterprise-managed-auth...

이게 일반 OAuth보다 어떤 장점이 있는지 잘 이해가 안 됨 인가 흐름 비교 예시가 필요할 것 같음

일반 OAuth에서는 최종 사용자가 각 애플리케이션에 자기 데이터를 공유할지 개별적으로 동의함
소비자 사용 사례, 즉 최종 사용자가 자기 데이터를 소유하는 경우에는 말이 됨
하지만 많은 비즈니스 사용 사례에서는 데이터를 공유하고 접근을 통제해야 하는 주체가 최종 사용자가 아니라 회사임
Acme 직원인 내가 Acme Google Drive 데이터를 Claude나 ChatGPT에 연결할지 결정해서는 안 되고, 그건 IT 부서가 결정해야 함 Enterprise-Managed OAuth, 또는 Cross App Access(XAA)는 IT 관리자가 중앙에서 제어하는 공유 모델을 OAuth 프레임워크 안으로 가져와 기존 생태계와 함께 동작하게 함
또 데이터 공유 동의 관리를 직원에서 IT 관리자로 옮기면 사용자 경험상 이점도 큼
직원이 계정을 연결하려고 여러 OAuth 흐름을 거칠 필요가 없고, IT 관리자가 이미 공유 제어를 설정해둔 상태가 됨
입사 첫날 Slack이 Zoom, Drive, Calendar 등에 이미 연결되어 있는 상황을 떠올리면 됨

장점은 사용자가 어떤 앱들이 서로 자기 정보를 공유하도록 인가되는지 제어하거나 동의할 필요가 없다는 것임
접근 위임 결정이 ID 제공자 정책 수준에서 내려지기 때문임
사용자는 어떤 앱이나 서비스가 자기 정보를 공유하도록 허가됐는지 영영 모를 수도 있음
잠깐, 그게 정말 장점인가? ;-)