MCP 서버에 OAuth 붙이기: 2026-07-28 인가 명세의 필수 구현 항목

MCP 서버를 사내 시스템 앞에 두는 순간, 그 서버는 AI 클라이언트와 실제 데이터 사이의 중간 계층이 된다. 인증을 느슨하게 만들면 클라이언트가 원래 볼 수 없는 데이터까지 서버를 통해 흘러나갈 수 있다. 이 글은 원격(HTTP) MCP 서버를 직접 구현하는 개발자를 위해, MCP 인가 명세 2026-07-28이 요구하는 항목을 구현 순서대로 정리한다. 로컬 stdio 서버는 명세상 이 절차 대신 환경 변수 등에서 자격 증명을 가져오도록 권하므로 대상이 아니다.

역할부터 맞추기: 서버는 리소스 서버다

명세에서 보호된 MCP 서버는 OAuth 2.1의 리소스 서버, MCP 클라이언트는 OAuth 2.1 클라이언트다. 토큰을 발급하는 인가 서버는 별도로 두거나 같은 곳에 둘 수 있다. 즉 MCP 서버가 직접 로그인 화면을 만들 필요는 없고, 기존 사내 인증 서버(IdP)를 인가 서버로 쓰면서 MCP 서버는 토큰을 검증하는 역할만 맡는 구성이 가능하다.

서버 구현 순서

1. 토큰 없는 요청에 401과 메타데이터 위치 알리기 — WWW-Authenticate 헤더에 resource_metadata URL과 이 요청에 필요한 최소 scope를 담는다.
2. Protected Resource Metadata 문서 제공 — /.well-known/oauth-protected-resource에서 자신의 식별자, 사용할 인가 서버, 기본 권한 범위를 알린다.
3. 토큰 대상(audience) 검증 — 받은 토큰이 이 서버를 대상으로 발급됐는지 확인한다. 클라이언트는 인가 요청에 이 서버의 정규 URI를 resource 파라미터로 보내야 한다(RFC 8707).
4. 권한 부족은 403으로 단계적 상향 요청 — 쓰기 같은 추가 권한이 필요한 작업이 들어오면 필요한 범위를 한 번에 담아 응답한다.
5. 하위 API에는 별도 자격 증명 사용 — 클라이언트에게 받은 토큰을 그대로 넘기지 않는다.

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource",
                         scope="files:read"

# GET /.well-known/oauth-protected-resource
{
  "resource": "https://mcp.example.com",
  "authorization_servers": ["https://auth.example.com"],
  "scopes_supported": ["files:read"]
}

# 권한이 부족한 요청에 대한 응답
HTTP/1.1 403 Forbidden
WWW-Authenticate: Bearer error="insufficient_scope",
                         scope="files:write",
                         resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

명세는 scopes_supported를 기본 동작에 필요한 최소 범위로 두고, 추가 권한은 이 403 응답을 통한 단계적 상향으로 요청하도록 안내한다. 클라이언트는 새로 인가받을 때 기존 범위와 새 범위의 합집합을 요청해 이전 권한을 잃지 않게 해야 한다.

토큰 전달(token passthrough)은 명시적 금지다

가장 흔한 설계 실수는 클라이언트에게 받은 토큰을 GitHub API나 사내 API 같은 하위 서비스에 그대로 넘기는 것이다. 명세는 MCP 서버가 자기 리소스용으로 유효한 토큰만 받아야 하며 다른 토큰을 수락하거나 전달해서는 안 된다고(MUST NOT) 규정한다. 보안 모범 사례 문서는 그 이유로 속도 제한·요청 검증 같은 하위 API의 통제를 우회하게 되고, 감사 로그에서 실제 요청 주체를 구분할 수 없게 되며, 탈취된 토큰으로 서버를 데이터 유출 경로로 쓸 수 있다는 점을 든다. 하위 API는 서버 자신의 자격 증명이나 별도로 발급받은 토큰으로 호출한다.

권한 범위는 도구 단위로 나눈다

보안 문서는 *, full-access 같은 포괄 범위와, 나중의 승인 요청을 피하려고 관련 없는 권한을 한꺼번에 묶는 것을 흔한 실수로 꼽는다. 실무에서는 도구를 읽기·쓰기·관리로 나누고 범위도 그에 맞춘다. 예를 들어 issues:read로 검색 도구를, issues:write로 코멘트 작성 도구를 허용하는 식이다. 도구 이름과 설명에도 데이터를 바꾸는 도구임을 드러내 두면 호스트에서 확인 절차를 켜기 쉽다. 요청마다 누가 어떤 도구를 어떤 범위로 호출했는지 기록해 두는 것도 잊지 않는다.

2026-07-28에서 달라진 인가 관련 항목

• 클라이언트는 인가 응답의 iss 값을 미리 기록한 인가 서버 식별자와 비교해야 한다(RFC 9207, 혼동 공격 방지).
• 동적 클라이언트 등록(RFC 7591)은 폐기 예정(Deprecated)이 되고 Client ID Metadata Documents가 권장 방식이 됐다.
• 클라이언트 자격 증명은 발급한 인가 서버에 묶이며, 인가 서버가 바뀌면 다시 등록해야 한다.

프로토콜 전체의 변경 사항은 MCP 2026-07-28 무상태 전환 가이드에서, MCP의 기본 구조는 MCP 개념 정리에서 먼저 확인할 수 있다. 서버 뒤의 데이터가 사내 문서라면 검색 단계의 권한 필터링은 사내 문서 RAG 접근 제어에서 이어서 다룬다.