원격 MCP 서버에 OAuth를 붙일 때 의외로 까다로운 부분은 로그인 화면이 아닙니다. 처음 만난 MCP 클라이언트를 인가 서버(Authorization Server)에 어떻게 등록할지가 더 큰 문제인데요. 데스크톱 앱, 코드 편집기, 에이전트 플랫폼을 인가 서버에 일일이 미리 등록할 수는 없기 때문입니다. 2025년 11월 25일 MCP 스펙은 이 문제를 풀기 위해 클라이언트 ID 메타데이터 문서(Client ID Metadata Documents, CIMD)를 권장 등록 방식으로 추가했습니다. 이전 스펙에서 사용하던 동적 클라
요즘 AI 에이전트가 단순히 질문에 답변만 하는 게 아니라, 실제로 사용자를 대신해서 외부 서비스를 호출하는 경우가 점점 늘고 있는데요. 예를 들어 코딩 에이전트한테 "Cloudflare에 새 워커를 배포해줘"라고 시키거나, 이메일 에이전트한테 "Resend로 뉴스레터 발송해줘"라고 부탁할 수 있습니다. 그런데 여기서 한 가지 문제가 생깁니다. 에이전트가 그 서비스에 가입되어 있어야 API를 호출할 수 있는데, 가입 자체가 사람을 전제로 만들어진 절차란 말이죠. 회원가입 폼, 이메일 인증, CAPTCHA, 대시보드 로그인 같은 단계
앱에 인증을 붙일 때 우리는 보통 한 방향만 생각합니다. 구글이나 회사 SSO 같은 외부 신원 제공자에 "우리 사용자 좀 로그인시켜 주세요" 하고 기대는 쪽이죠. WorkOS로 엔터프라이즈 SSO 붙이기에서 다룬 게 딱 이 방향입니다. 그런데 서비스가 자리를 잡으면 반대 요구가 들어오기 시작해요. "당신 서비스의 계정으로 우리 앱에 로그인하게 해주세요", "그 사용자의 데이터를 API로 가져가게 해주세요" 하고 이번엔 다른 앱들이 우리에게 기대오는 겁니다. "Google로 로그인"이나 "GitHub로 로그인" 버튼을 우리 서비스 이
B2C 서비스를 잘 운영하다가 엔터프라이즈 고객과 계약을 앞두면 십중팔구 듣게 되는 말이 있는데요. "저희는 Okta로 SSO 연동해야 합니다. SAML 메타데이터 보내드릴게요." "Azure AD 그룹 그대로 사용자 프로비저닝 되죠? SCIM 스펙 문서 공유 드립니다." 이때부터 일이 커집니다. SAML 명세는 두껍고, 고객사마다 IdP가 Okta, Azure AD, Google Workspace, OneLogin, Ping 등으로 제각각이라 각 IdP의 설정 화면까지 안내해야 해요. WorkOS는 이 고통을 표준화된 API 하나