MCP 서버가 내 서비스의 데이터나 작업을 대신 실행하기 시작하면 ‘연결된다’는 사실보다 누가 무엇을 할 수 있는지가 중요해집니다. 토큰을 발급받았다는 이유만으로 모든 도구를 호출할 수 있게 만들면 권한 경계가 사라집니다.이번 글에서는 MCP Authorization 사양에서 강조하는 resource indicator와 PKCE를 중심으로, 구현 전에 확인할 보안 질문을 정리합니다. 인증 라이브러리와 사양 버전은 구현 시점에 다시 확인해야 합니다.인증과 권한을 분리해서 설계합니다인증은 요청자가 누구인지 확인하는 절차이고, 권한은 그 요청자가 특정 리소스와 도구를 사용할 수 있는지 확인하는 절차입니다. OAuth가 성공했다고 해서 서버의 모든 기능을 허용하면 안 됩니다.저는 서버를 연결할 때 데이터 읽기,..

회원가입을 요구하지 않는 서비스는 진입 장벽이 낮다는 장점이 있습니다. 대신 한 사람이 반복 요청을 보내도 누구인지 구분하기 어렵고, 공격과 정상 사용을 구분할 정보가 부족합니다.저는 처음부터 복잡한 인증을 붙이기보다 서비스가 감당할 수 있는 행동의 범위를 정했습니다. 이번 글에서는 경로별 제한, 사용자 식별, 실패 응답, 관찰 지표를 최소 구성으로 나눠 보겠습니다.막아야 할 행동을 먼저 정의합니다스팸은 사용자라는 사람이 아니라 행동의 패턴으로 나타납니다. 짧은 시간에 같은 요청을 반복하거나, 파일 크기가 비정상적으로 크거나, 실패한 요청만 계속 보내는 식입니다. 무엇을 막을지 정하지 않고 방어 도구부터 붙이면 정상 사용도 함께 막힙니다.저는 엔드포인트마다 비용과 피해를 적습니다. 읽기 요청과 데이터 생..