MCP 서버의 인증과 도구 권한 경계를 설계하는 법

MCP 서버의 권한 경계는 “인증된 사용자냐”에서 끝나지 않습니다. 어떤 클라이언트가 어떤 서버를 대상으로 어떤 도구를 호출할 수 있는지, 읽기와 변경을 어디서 분리할지까지 요청마다 판정해야 합니다. 가장 작은 권한으로 시작하고 변경 작업은 별도 승인을 요구하는 것이 기본 설계입니다.

이 글은 HTTP 기반 MCP 서버를 운영한다고 가정해 인증 흐름과 도구 권한을 분해합니다. STDIO 서버처럼 환경 변수에서 자격 증명을 받는 구성은 같은 OAuth 흐름을 그대로 적용하지 말고 전송 방식의 보안 경계를 별도로 검토해야 합니다.

구성 요소와 요청 경계를 그립니다

인증은 토큰이 누구 또는 어떤 클라이언트에서 왔는지 확인하는 일이고, 인가는 그 토큰이 특정 도구와 리소스에 접근할 수 있는지 확인하는 일입니다. 2025-11-25 MCP 권한 명세는 HTTP 전송에 대한 OAuth 기반 흐름을 설명하며, 토큰이 의도한 MCP 서버를 대상으로 발급되었는지 검증하도록 요구합니다. 이 명세에서 클라이언트와 인증 서버는 Client ID Metadata Documents를 지원하는 것이 권장되고, Dynamic Client Registration은 선택 사항입니다.MCP Authorization 명세를 서버와 클라이언트 구현의 기준으로 삼습니다.

도구·리소스 권한을 매핑합니다

도구 이름만 보고 권한을 주지 말고 읽기, 생성, 수정, 삭제, 외부 전송으로 분류합니다. read_ticket은 조회 권한, update_ticket은 특정 프로젝트 범위와 승인 권한, delete_ticket은 관리자와 재확인 절차가 필요할 수 있습니다. 도구가 접근하는 리소스의 소유자와 tenant도 토큰의 범위와 함께 대조합니다.

1. 요청의 토큰 대상과 issuer·만료를 검증한다.

2. 도구·작업·리소스 범위를 매칭한다.

3. 변경 작업이면 사용자 확인과 감사 기록을 남긴다.

가상 사례: 티켓 도구 두 개를 노출하기

가상 사례의 입력은 고객지원 에이전트가 보낸 티켓 조회 또는 상태 변경 요청입니다. 결정은 조회 도구에는 support:read 범위만 허용하고, 상태 변경에는 support:write와 티켓 소유 팀 확인을 모두 요구하는 것입니다. 중간 산출물은 tool, resource, decision, confirmation_id를 담은 인가 기록이며, 기대 결과는 권한 없는 변경이 실행되지 않는 것입니다.

실패하면 토큰을 다른 서버로 넘기지 않습니다

토큰 검증이 실패하거나 대상 서버가 다르면 도구를 호출하지 않고 401 또는 403과 추적 ID만 반환합니다. 만료된 토큰은 조용히 재사용하지 말고 정해진 인증 흐름으로 다시 받습니다. 동의 화면이나 redirect URI가 맞지 않으면 대체 URL로 보내지 않고 중단해야 합니다. 복구는 재인증 또는 운영자 확인으로 제한합니다. 로그에는 토큰 원문 대신 subject, server_id, tool, decision만 남깁니다.

반례는 로컬 개발용 STDIO 서버입니다. 외부 HTTP 리소스 소유자를 대신하는 OAuth 모델을 억지로 붙이기보다 프로세스 경계, 환경 변수 보호, 도구 allowlist, 개발 데이터 격리를 점검하는 편이 맞습니다. 운영 HTTP 서버로 전환할 때는 인증 설계를 다시 검토합니다.

완료 조건

검증 완료는 정상 토큰, 다른 서버 대상 토큰, 만료 토큰, 읽기 전용 범위의 변경 요청을 각각 재현하고, 거부된 호출이 실행되지 않으며, 성공·실패 결정과 승인 식별자가 감사 기록에 남는 것을 확인한 상태입니다.