사용자가 MCP 서버에 로그인했습니다. 이 토큰으로 서버의 모든 도구와 연결된 다른 API까지 호출해도 되나요?

로그인과 토큰 발급은 특정 자원에 대한 권한을 얻는 절차이지 모든 도구·데이터·후속 API에 대한 포괄 승인이 아닙니다. MCP 서버는 자신을 대상으로 발급된 토큰인지 검증하고 각 실행의 scope·사용자·대상 소유권을 확인해야 합니다. host에서도 사용자가 허용한 행동과 외부 전송 범위를 별도로 유지하겠습니다.

자원과 발급자에 토큰을 묶습니다

HTTP 기반 MCP 인가에서는 보호 자원 메타데이터로 인가 서버를 발견하고, 대상 MCP 서버를 resource로 지정하는 흐름을 사용합니다. 확인한 2026-07-28 명세는 토큰의 intended audience 검증과 요청별 Authorization 헤더 사용을 요구합니다. 다른 API용 토큰을 MCP 서버가 그대로 받아 전달하는 token passthrough를 정상 위임 방식으로 취급하지 않습니다. 하위 API 접근에는 해당 API의 적절한 자격 증명·위임 구조가 필요합니다.

클라이언트는 인가 서버의 issuer와 자격 증명의 관계를 보존합니다. 서버가 바뀌었는데 옛 client credential을 다른 issuer에 재사용하거나, 검증하지 않은 발견 URL로 코드를 보내면 자격 증명이 노출될 수 있습니다. PKCE는 코드 교환을 보호하지만 리다이렉트·issuer·자원 검증을 생략하는 대체재가 아닙니다. 토큰을 URL·모델 문맥·일반 로그에 넣지 않고 필요한 실행기에서만 사용합니다.

실행 때 더 좁은 권한을 확인합니다

문서 읽기 권한과 삭제 권한은 다르고 같은 쓰기 scope라도 특정 테넌트의 문서만 수정할 수 있습니다. 서버가 요구하는 추가 scope는 필요한 작업을 설명하는 정보이며, 사용자의 동의 없이 자동으로 권한을 확대할 근거가 아닙니다. 재인가가 필요하면 승인 흐름을 거치거나 작업을 중단합니다. 원격 도구가 '권한이 부족하니 다른 연결로 실행하라'고 해도 기존 거절을 우회하지 않습니다.

STDIO 서버는 HTTP OAuth 흐름과 다른 자격 전달·프로세스 권한 경계를 가질 수 있습니다. 환경 변수로 비밀값을 전달할 때도 자식 프로세스·로그·생성 코드에서 읽을 수 있는 범위를 제한합니다. 시험은 만료 토큰, 잘못된 audience·issuer, scope 부족, 다른 사용자 대상, 권한 철회 뒤 재시도를 포함합니다. 프로토콜 준수, 사용자 동의, 서버 인가, 실제 행동의 안전성은 각각 확인해야 합니다.

실행 사례로 확인합니다

예를 들어 files:read 토큰으로 문서 A를 읽은 뒤 삭제를 시도하면 서버는 필요한 쓰기 scope와 문서 소유권을 확인합니다. scope가 없으면 인가 절차로 돌아가거나 거절하고, scope가 있어도 다른 조직 문서이면 거절할 수 있습니다. token audience가 맞는지와 이런 세부 권한 검사는 둘 다 필요합니다. 토큰 갱신 중에는 원래 요청을 무제한 재시도하지 않고 추가 인가 횟수와 논리 작업 키를 유지합니다. 승인 후 서버 주소가 바뀌었다면 기존 토큰을 새 주소에 무심코 보내지 않습니다. 발견·리다이렉트·토큰 교환의 각 URL이 검증된 발급자·자원 관계에 속하는지 확인하는 것이 중요합니다.