MCP OAuth 권한·PKCE·resource indicator 적용 점검표

MCP 서버가 내 서비스의 데이터나 작업을 대신 실행하기 시작하면 ‘연결된다’는 사실보다 누가 무엇을 할 수 있는지가 중요해집니다. 토큰을 발급받았다는 이유만으로 모든 도구를 호출할 수 있게 만들면 권한 경계가 사라집니다.

이번 글에서는 MCP Authorization 사양에서 강조하는 resource indicator와 PKCE를 중심으로, 구현 전에 확인할 보안 질문을 정리합니다. 인증 라이브러리와 사양 버전은 구현 시점에 다시 확인해야 합니다.

인증과 권한을 분리해서 설계합니다

인증은 요청자가 누구인지 확인하는 절차이고, 권한은 그 요청자가 특정 리소스와 도구를 사용할 수 있는지 확인하는 절차입니다. OAuth가 성공했다고 해서 서버의 모든 기능을 허용하면 안 됩니다.

저는 서버를 연결할 때 데이터 읽기, 데이터 수정, 작업 실행을 별도 범위로 나눕니다. 읽기 전용으로 시작하고, 꼭 필요한 경우에만 수정 권한을 추가합니다.

• 인증: 사용자·클라이언트·세션의 신원을 확인합니다.
• 리소스 대상: 발급된 토큰이 어느 MCP 서버를 위한 것인지 확인합니다.
• 권한 범위: 도구와 리소스별 허용 동작을 제한합니다.

resource indicator는 토큰의 대상을 묶습니다

MCP Authorization 사양은 OAuth 요청과 토큰 요청에 resource parameter를 포함해 토큰이 의도한 서버를 식별하도록 요구합니다. 토큰이 다른 리소스에 재사용되지 않게 대상 서버의 canonical URI를 명확히 하는 것이 핵심입니다.

구현에서는 문자열 비교가 느슨해지지 않도록 URI 규칙과 리디렉션을 고정합니다. 개발·스테이징·운영 서버가 다르면 각각의 대상을 분리합니다.

점검질문실패 예

대상 URI	토큰이 어느 서버용인가	모든 서버에 같은 audience
요청 일치	인가·토큰 요청의 대상이 같은가	한쪽만 resource 누락
환경 분리	개발 토큰이 운영에 쓰이지 않는가	느슨한 리디렉션

PKCE는 인증 코드 가로채기를 줄입니다

PKCE는 클라이언트가 만든 verifier와 challenge를 이용해 인증 코드를 원래 요청자만 토큰으로 교환할 수 있게 합니다. 클라이언트 비밀을 안전하게 보관하기 어려운 환경에서는 특히 중요한 보호 장치입니다.

PKCE를 넣었다고 인증이 끝나는 것은 아닙니다. redirect URI 검증, state 확인, 토큰 저장 위치, 만료와 폐기 정책도 함께 점검해야 합니다. 샘플 코드의 편의를 위해 검증을 생략하지 않습니다.

• verifier: 클라이언트가 임의로 만들고 안전하게 보관하는 값입니다.
• challenge: 인가 요청에 보내는 verifier의 검증 값입니다.
• redirect 검증: 허용된 URI 외의 이동을 막습니다.
• 토큰 보관: 브라우저·로그·에러 메시지에 노출하지 않습니다.

도구 승인 화면은 권한을 설명해야 합니다

사용자가 ‘허용’ 버튼만 보고 무엇을 승인하는지 모르면, 권한이 커질수록 위험이 커집니다. 어떤 데이터에 접근하고 어떤 작업을 실행하는지, 언제까지 유효한지 설명해야 합니다.

도구 호출마다 추가 확인이 필요한 작업과 한 번 승인해도 되는 읽기 작업을 구분하면 보안과 사용성을 함께 지킬 수 있습니다. 로그에는 토큰 대신 요청 ID와 권한 결과만 남깁니다.

AI 도구를 사용할 때 남겨야 할 경계

AI 도구는 조사와 구조화에 도움을 주지만, 결과의 책임까지 가져가지는 않습니다. 저는 작업을 시작할 때 입력에 포함해도 되는 정보, 외부 출처로 확인해야 하는 주장, 사람이 직접 판단해야 하는 결과를 구분합니다. 이 세 가지가 섞이면 AI가 만든 문장이나 도구 호출을 실제 경험과 사실처럼 받아들이기 쉽습니다.

작은 샘플로 실행한 뒤 기록을 검토하는 것도 중요합니다. 프롬프트·도구 인자·응답·파일 결과 중 무엇을 보관할지 정하고, 민감정보와 권한을 최소화합니다. 한 번 잘 나온 결과보다 같은 조건에서 다시 확인할 수 있는 과정이 더 오래 남는 자산입니다. 최신 사양과 정책을 다루는 글은 조사일과 버전을 고정하고 발행 전에 공식 문서를 다시 읽습니다.

• 입력 범위: 원고·개인정보·토큰·파일 경로 중 무엇을 보내지 않을지 정합니다.
• 근거: 공식 문서와 직접 경험을 분리해 기록하고 URL을 보관합니다.
• 검수: 사실·출처·문체·권한·재현성을 사람이 확인합니다.
• 중단 조건: 결과가 반복되지 않거나 비용·권한이 커지면 사용을 멈춥니다.

다음 작업에서 다시 확인할 항목

한 번 적용한 방법이 언제나 같은 결과를 내는 것은 아닙니다. 사람과 서비스와 원고의 조건이 바뀌면 같은 원칙도 다른 판단을 요구합니다. 그래서 저는 글을 작성한 뒤 결론만 보관하지 않고, 결론이 성립한 조건과 다시 확인해야 할 조건을 함께 적습니다. 이 기록이 있으면 몇 달 뒤 글을 업데이트할 때 당시의 경험을 현재의 사실처럼 착각하지 않을 수 있습니다.

특히 버전·정책·가격·플랫폼 기능처럼 외부에서 바뀌는 내용은 조사한 날짜와 공식 문서의 주소를 남깁니다. 발행 시점에 문서가 달라졌다면 본문에 변경 사실을 표시하고, 직접 확인하지 못한 부분은 독자가 알 수 있도록 범위를 제한합니다. 경험을 공유하는 글도 다른 사람의 환경에 그대로 적용될 수 있으므로, 성공 사례보다 실패 조건을 함께 쓰는 편이 안전합니다.

마지막으로 이 글을 읽은 분이 바로 할 수 있는 행동은 하나로 줄입니다. 모든 항목을 한꺼번에 바꾸기보다 현재 상태를 기록하고, 작은 실험을 한 번 실행하고, 결과를 다시 적는 순서입니다. 그렇게 쌓인 기록이 다음 글의 소재가 되고, 처음의 판단을 더 정확하게 고쳐 쓰는 근거가 됩니다.

• 범위 표시: 이 글의 결론이 적용되는 환경과 적용되지 않는 환경을 구분합니다.
• 날짜 기록: 버전·정책·가격·문서를 확인한 날짜를 남깁니다.
• 실패 조건: 어떤 상황에서는 이 방법을 쓰지 말아야 하는지 적습니다.
• 작은 실행: 독자가 오늘 시도할 수 있는 가장 작은 행동을 고릅니다.
• 후속 기록: 실행 결과와 다음에 바꿀 조건을 별도 메모로 남깁니다.

이 기록을 나중에 다시 읽을 때는 결과만 보지 않고 당시의 조건도 함께 확인합니다. 조건이 달라졌다면 결론을 그대로 복사하지 말고 현재의 입력과 제약을 다시 적습니다. 그 과정을 거쳐야 이 글이 단순한 경험담이 아니라 다음 판단을 돕는 작업 기록으로 남습니다.

마치며

MCP 인증의 핵심은 연결에 성공하는 것이 아니라 토큰의 대상과 도구의 권한을 좁게 유지하는 것입니다. 구현 전에 서버 URI·PKCE·redirect·권한 범위·토큰 보관 위치를 한 장의 점검표로 만들어 보시기 바랍니다.

참고한 문서: MCP Authorization 사양 · MCP 기본 사양