권한 부여 보안 고려 사항

권한 부여 보안 고려 사항 (Authorization Security Considerations)

MCP 클라이언트와 서버를 구축할 때 구현자가 반드시 고려해야 할 보안 요구사항을 설명하는 페이지예요. 토큰 audience 바인딩, 토큰 도난, 통신 보안, 인증 코드 보호, mix-up 및 confused deputy 공격, 오픈 리다이렉션, Client ID Metadata Document 보안을 다뤄요.

출처: 문서

본문

이 문서는 MCP 클라이언트와 서버를 구축할 때 구현자가 MUST 고려해야 할 보안 요구사항을 개괄해요.

또한 구현자는 OAuth 2.1 Section 7. "Security Considerations"에 개괄된 OAuth 2.1 보안 모범 사례를 MUST 따라야 해요.

토큰 Audience 바인딩과 검증 (Token Audience Binding and Validation)

RFC 8707 Resource Indicators는 Authorization Server가 이 기능을 지원할 때 토큰을 의도된 audience에 바인딩해 중요한 보안 이점을 제공해요. 현재와 미래의 채택을 가능하게 하려면:

MCP 클라이언트는 MUST Resource Parameter Implementation 섹션에 명시된 대로 권한 부여 및 토큰 요청에 resource 파라미터를 포함해야 한다
MCP 서버는 MUST 자신에게 제시된 토큰이 자신의 사용을 위해 특별히 발행되었는지 검증해야 한다

Security Best Practices 문서는 토큰 audience 검증이 왜 중요한지, 토큰 패스스루가 왜 명시적으로 금지되는지 개괄해요.

토큰 도난 (Token Theft)

클라이언트가 저장한 토큰, 또는 서버가 캐시하거나 로깅한 토큰을 얻은 공격자는 리소스 서버에게 정당해 보이는 요청으로 보호된 리소스에 접근할 수 있어요.

클라이언트와 서버는 MUST OAuth 2.1, Section 7.1에 개괄된 대로 안전한 토큰 저장을 구현하고 OAuth 모범 사례를 따라야 해요.

인증 서버는 SHOULD 노출된 토큰의 영향을 줄이기 위해 수명이 짧은 접근 토큰을 발행해야 해요. 공개(public) 클라이언트의 경우, 인증 서버는 MUST OAuth 2.1 Section 4.3.1 "Token Endpoint Extension"에 설명된 대로 리프레시 토큰을 회전시켜야 해요.

통신 보안 (Communication Security)

구현은 MUST OAuth 2.1 Section 1.5 "Communication Security"를 따라야 해요.

구체적으로:

모든 인증 서버 엔드포인트는 MUST HTTPS로 서비스되어야 한다.
모든 redirect URI는 MUST localhost이거나 HTTPS를 사용해야 한다.

인증 코드 보호 (Authorization Code Protection)

권한 부여 응답에 포함된 인증 코드에 접근한 공격자는 인증 코드를 접근 토큰으로 교환하거나 다른 방식으로 사용하려 할 수 있어요. (OAuth 2.1 Section 7.5에서 더 설명됨)

이를 완화하려면 MCP 클라이언트는 MUST OAuth 2.1 Section 7.5.2에 따라 PKCE를 구현하고, 권한 부여를 진행하기 전에 MUST PKCE 지원을 확인해야 해요. PKCE는 클라이언트가 비밀 검증자-도전(verifier-challenge) 쌍을 만들도록 요구해서 인증 코드 가로채기와 주입 공격을 방지하고, 원래 요청자만 인증 코드를 토큰으로 교환할 수 있게 보장해요.

MCP 클라이언트는 MUST OAuth 2.1 Section 4.1.1이 요구하는 대로 기술적으로 가능할 때 S256 코드 도전 방식을 사용해야 해요.

OAuth 2.1과 PKCE 사양은 클라이언트가 PKCE 지원을 발견하는 메커니즘을 정의하지 않으므로, MCP 클라이언트는 MUST 이 기능을 확인하기 위해 인증 서버 메타데이터에 의존해야 해요:

OAuth 2.0 Authorization Server Metadata: code_challenge_methods_supported가 없으면, 인증 서버는 PKCE를 지원하지 않으며 MCP 클라이언트는 MUST 진행을 거부해야 한다.
OpenID Connect Discovery 1.0: OpenID Provider Metadata가 code_challenge_methods_supported를 정의하지는 않지만, 이 필드는 OpenID 제공자가 일반적으로 포함해요. MCP 클라이언트는 MUST 제공자 메타데이터 응답에 code_challenge_methods_supported 존재를 확인해야 한다. 필드가 없으면 MCP 클라이언트는 MUST 진행을 거부해야 한다.

OpenID Connect Discovery 1.0을 제공하는 인증 서버는 MUST MCP 호환성을 보장하기 위해 메타데이터에 code_challenge_methods_supported를 포함해야 해요.

Mix-Up 공격 (Mix-Up Attacks)

MCP 클라이언트가 상호작용하는 인증 서버 중 하나를 통제하는 공격자는, 클라이언트가 다른 정직한 인증 서버가 발행한 인증 코드나 토큰을 자신에게 보내게 하려 할 수 있어요(mix-up 공격, RFC9207 Section 1에서 설명됨). Authorization Response Validation이 필요한 완화를 지정해요.

오픈 리다이렉션 (Open Redirection)

공격자는 악의적인 redirect URI를 만들어 사용자를 피싱 사이트로 유도할 수 있어요.

MCP 클라이언트는 MUST 인증 서버에 redirect URI를 등록해야 해요.

인증 서버는 MUST 정확한 redirect URI를 사전 등록된 값에 대해 검증해 리다이렉션 공격을 방지해야 해요.

MCP 클라이언트는 SHOULD 인증 코드 흐름에서 state 파라미터를 사용하고 검증하며, 원래 state를 포함하지 않거나 불일치하는 결과는 폐기해야 해요.

인증 서버는 MUST OAuth 2.1 Section 7.12.2에 제시된 제안을 따라 신뢰할 수 없는 URI로 사용자 에이전트를 리다이렉트하지 않도록 예방 조치를 취해야 해요.

인증 서버는 SHOULD 리다이렉션 URI를 신뢰할 때만 사용자 에이전트를 자동으로 리다이렉트해야 해요. URI를 신뢰할 수 없으면, 인증 서버는 MAY 사용자에게 알리고 사용자가 올바른 결정을 내리도록 의존할 수 있어요.

Client ID Metadata Document 보안 (Client ID Metadata Document Security)

Client ID Metadata Documents를 구현할 때, 인증 서버는 MUST OAuth Client ID Metadata Document, Section 6에 자세히 설명된 보안 영향을 고려해야 해요. 핵심 고려 사항:

Authorization Server 남용 방지 (Authorization Server Abuse Protection)

메타데이터 문서를 가져오는 인증 서버는 SHOULD OAuth Client ID Metadata Document: Server Side Request Forgery (SSRF) Attacks에서 설명된 대로 Server-Side Request Forgery (SSRF) 위험을 고려해야 해요.

Localhost Redirect URI 위험 (Localhost Redirect URI Risks)

Client ID Metadata Documents는 그 자체로 localhost URL 가장(impersonation)을 막을 수 없어요.

인증 서버는:

SHOULD localhost 전용 redirect URI에 추가 경고를 표시해야 한다
MAY 향상된 보안을 위해 추가 증명(attestation) 메커니즘을 요구할 수 있다
MUST 권한 부여 중 redirect URI 호스트명을 명확히 표시해야 한다

신뢰 정책 (Trust Policies)

인증 서버는 MAY Client ID Metadata Document 사양의 Section 6.4와 Section 6.8에 설명된 대로 Client ID Metadata Documents를 수락하기 위한 도메인 기반 신뢰 정책을 구현할 수 있어요.

Confused Deputy 문제 (Confused Deputy Problem)

공격자는 제3자 API에 대한 중간자(intermediary)로 동작하는 MCP 서버를 악용해 confused deputy 취약점을 만들 수 있어요. 도난된 인증 코드를 사용해 사용자 동의 없이 접근 토큰을 얻을 수 있어요.

정적 클라이언트 ID를 사용하는 MCP 프록시 서버는 MUST 제3자 인증 서버로 전달하기 전에 각 동적으로 등록된 클라이언트에 대해 사용자 동의를 받아야 해요 (추가 동의가 필요할 수 있음).

접근 토큰 권한 제한 (Access Token Privilege Restriction)

공격자는 서버가 다른 리소스를 위해 발행된 토큰을 수락하면 무단 접근을 얻거나 MCP 서버를 손상시킬 수 있어요.

MCP 서버는 MUST 요청을 처리하기 전에 접근 토큰을 검증해 접근 토큰이 MCP 서버를 위해 특별히 발행되었는지 확인하고, 무단 당사자에게 데이터가 반환되지 않도록 필요한 모든 조치를 취해야 해요.

MCP 서버는 MUST 인바운드 토큰 검증을 위해 OAuth 2.1 - Section 5.2의 지침을 따라야 해요.

MCP 서버는 MUST 자신을 위해 특별히 의도된 토큰만 수락하고, audience 클레임에 자신을 포함하지 않는 토큰을 MUST 거부하거나 자신이 의도된 수신자임을 달리 확인해야 해요. 자세한 내용은 Security Best Practices Token Passthrough 섹션을 참조하세요.

MCP 서버가 업스트림 API에 요청을 하면, 그들에게 OAuth 클라이언트로 동작할 수 있어요. 업스트림 API에서 사용되는 접근 토큰은 업스트림 인증 서버가 발행한 별도의 토큰이에요. MCP 서버는 MUST NOT MCP 클라이언트로부터 받은 토큰을 패스스루해서는 안 돼요.

MCP 클라이언트는 MUST RFC 8707 - Resource Indicators for OAuth 2.0에 정의된 resource 파라미터를 구현하고 사용해 토큰이 요청되는 대상 리소스를 명시적으로 지정해야 해요. 이 요구사항은 RFC 9728 Section 7.4의 권고와 정렬돼요. 이는 접근 토큰이 의도된 리소스에 바인딩되고 서로 다른 서비스에 걸쳐 오용될 수 없도록 보장해요.

권한 부여 보안 고려 사항