authgent라는 오픈소스 검사기가 운영 중인 MCP 서버 30곳의 OAuth 설정을 훑어 A 한 곳·B 16곳·C 10곳·F 3곳으로 매겼다고 저장소 안 홍보 문서에 적어 놨어요. 검사는 서버가 `.well-known`으로 내놓는 메타데이터를 읽는 방식이라 실제로 어떻게 동작하는지는 안 건드리고, 30곳 명단과 A를 받은 한 곳은 어디에도 공개돼 있지 않아요. 등급을 끌어내린 항목은 '토큰을 어느 서버용으로 발급받는지 밝히는 리소스 지시자(RFC 8707)를 안 알린다'로 30곳 중 29곳이 걸렸는데, MCP 규격이 이걸 반드시 하라고 못 박은 쪽은 서버가 아니라 클라이언트예요.
용어 풀이
- MCP
- AI 도구를 외부 서비스·데이터에 붙이는 연결 규격
- OAuth
- 비밀번호를 넘기지 않고 권한만 위임하는 인증 표준
- PKCE
- 인증 코드를 가로채도 못 쓰게 막는 OAuth 보호 장치. plain 방식은 사실상 보호가 안 돼 금지
- RFC 9728
- MCP 서버가 '내 인증 서버는 여기'라고 알리는 규격. MCP 규격이 서버에 필수로 요구
- RFC 8707
- 토큰을 쓸 대상 서버를 지정해 다른 서버에 재사용하지 못하게 묶는 규격
운영자 인사이트
사내에 MCP 서버를 붙여 쓴다면 `.well-known/oauth-protected-resource`가 응답하는지, PKCE 설정에 plain이 섞여 있지 않은지는 curl로 몇 분이면 확인돼요. 다만 이런 메타데이터 점검은 앞사람 토큰이 뒷사람 요청에 실려 나가던 테라폼 MCP 서버 같은 버그는 못 잡으니, 토큰이 우리 서버용으로 발급된 게 맞는지 확인하는 코드는 따로 읽어 봐야 해요.
여러 관점으로 보기
- 검사 기준 검사 항목은 열 가지고 그중 일곱 개만 등급에 반영돼요. 100점에서 깎는 방식이라 심각 하나면 A에서 D로 떨어지고, A는 95점 이상이어야 해요. GitHub
- 규격 원문 MCP 규격은 서버에 RFC 9728 구현을 필수로 못 박았지만, 리소스 지시자는 '인증 서버가 지원하든 안 하든 클라이언트가 보내라'는 클라이언트 의무로 적어 놨어요. Model Context Protocol
- 만든 쪽의 목적 저장소 `tools/`에 해커뉴스 올릴 시각과 목표 별 수까지 적은 홍보 계획 문서가 같이 들어 있어요. 파는 유료 제품은 없고, 알리려는 건 자기 검사기와 자기 OAuth 서버 구현이에요. GitHub