MCP 인가(Authorization)와 아무도 이야기하지 않는 공격 표면(Attack Surface)

최근 포춘 500대 기업의 한 AI 에이전트가 직원들의 이메일을 무단으로 읽기 시작한 사건이 발생했습니다. 에이전트가 애초에 그렇게 설계되었기 때문이 아닙니다. 에이전트가 연결한 MCP 서버가 완전히 다른 서비스용으로 발급된 토큰을 그대로 수락했기 때문입니다. 해당 토큰의 대상자(audience) 클레임에는 “internal-calendar-api”라고 명시되어 있었지만, MCP 서버는 이를 전혀 검증하지 않았습니다.

이것이 바로 ‘토큰 패스스루(Token Passthrough)’ 문제입니다. 그리고 이는 MCP 서버를 구축하는 모든 엔지니어링 팀이 반드시 이해해야 하는 보안 아키텍처의 핵심에 자리 잡고 있습니다.

인가 아키텍처 (The Authorization Architecture)

MCP는 완전히 새로운 인증/인가 시스템을 만들지 않았습니다. 대신 아이덴티티 생태계 전반에서 철저히 검증된 OAuth 2.1과 일련의 RFC 기반 표준 스택을 토대로 구축되었습니다:

표준 (Standard)	역할 (What It Does)
OAuth 2.1 (초안)	핵심 인가 프레임워크 (Core authorization framework)
RFC 8414	인가 서버 메타데이터 탐색 (Authorization Server Metadata discovery)
RFC 7591	동적 클라이언트 등록 (Dynamic Client Registration, DCR)
RFC 9728	보호된 리소스 메타데이터 (Protected Resource Metadata, PRM)
RFC 8707	리소스 지시자 (Resource Indicators)

MCP 서버에서 인가(Authorization) 구현은 규격상 선택 사항(optional)입니다. 하지만 서버가 사용자 데이터를 다루거나, 감사 추적(audit trail)이 필요하거나, 동의(consent)가 필요한 API를 노출하거나, 엔터프라이즈 환경에서 운영되는 경우에는 절대 선택 사항이 아닙니다. 다시 말해, 프로덕션 환경에서는 필수입니다.

유일한 예외는 STDIO 트랜스포트를 사용하는 로컬 MCP 서버입니다. 로컬 서버는 사용자의 머신에서 직접 실행되므로 환경 변수 기반 자격 증명, 임베디드 라이브러리, 또는 파일시스템 접근 패턴을 활용할 수 있습니다. OAuth 흐름은 서버가 원격에 호스팅되는 HTTP 기반 트랜스포트를 위해 설계되었습니다.

6단계 인가 흐름 (The Six-Step Flow)

인가가 적용된 모든 MCP 연결은 동일한 흐름을 따릅니다:

1단계: 401 응답 (The 401). 클라이언트가 연결을 시도하면, 서버는 401 Unauthorized 상태 코드와 함께 보호된 리소스 메타데이터(Protected Resource Metadata, PRM) 문서를 가리키는 WWW-Authenticate 헤더로 응답합니다.

2단계: PRM 탐색 (PRM Discovery). 클라이언트는 PRM 문서를 조회하여 어떤 인가 서버(Authorization Server)가 이 리소스를 보호하는지, 지원되는 스코프(scopes)는 무엇인지, 기타 메타데이터를 파악합니다.

3단계: 인가 서버 메타데이터 탐색 (Authorization Server Discovery). 클라이언트는 인가 서버의 메타데이터(인가 엔드포인트, 토큰 엔드포인트, 등록 엔드포인트, 발급자 URL)를 조회합니다. 이 과정에는 OIDC Discovery 또는 OAuth 2.0 인가 서버 메타데이터(RFC 8414)가 사용됩니다.

4단계: 클라이언트 등록 (Client Registration). 클라이언트는 사전에 등록된 자격 증명을 내장하고 있거나, 동적 클라이언트 등록(Dynamic Client Registration, DCR)을 통해 인가 서버에 자신을 등록합니다. 둘 다 불가능한 경우, 클라이언트 개발자는 수동으로 자격 증명을 입력받는 UI/UX 인터페이스를 제공해야 합니다.

5단계: 사용자 인가 (User Authorization). 클라이언트는 브라우저를 열어 인가 엔드포인트로 이동합니다. 사용자가 인증을 거쳐 요청된 스코프에 동의하면, 인가 서버는 인가 코드(authorization code)와 함께 리디렉션합니다. 클라이언트는 PKCE가 적용된 표준 OAuth 2.1 인가 코드 흐름에 따라 이 코드를 액세스 토큰(access token) 및 리프레시 토큰(refresh token)으로 교환합니다.

6단계: 인증된 요청 전송 (Authenticated Requests). 이후의 모든 요청은 Authorization: Bearer 헤더에 액세스 토큰을 포함하여 전송됩니다. MCP 서버는 인가 서버에 인트로스펙션(introspection)을 요청하거나 직접 검증하여 토큰의 유효성을 확인하고, 토큰이 유효하며 필요한 스코프를 가지고 있는 경우에만 요청을 처리합니다.

┌──────────────────────────────────────────────────────────────┐
│                    MCP AUTHORIZATION FLOW                     │
│                                                              │
│  MCP Client                                                  │
│      │                                                       │
│      ├──1──> MCP Server                                      │
│      │       └── 401 + resource_metadata URL                 │
│      │                                                       │
│      ├──2──> Fetch PRM Document                              │
│      │       └── authorization_servers, scopes_supported     │
│      │                                                       │
│      ├──3──> Fetch Auth Server Metadata                      │
│      │       └── authorize, token, registration endpoints    │
│      │                                                       │
│      ├──4──> Client Registration (DCR or pre-registered)     │
│      │       └── client_id, redirect_uri                     │
│      │                                                       │
│      ├──5──> User Authorizes (browser + PKCE)                │
│      │       └── access_token, refresh_token                 │
│      │                                                       │
│      └──6──> Authenticated MCP Requests                      │
│              └── Authorization: Bearer <token>               │
└──────────────────────────────────────────────────────────────┘

토큰 검증: 가장 중요한 관문 (Token Validation: The Critical Gate)

MCP 서버는 전달받은 토큰을 맹목적으로 신뢰해서는 안 되며, 반드시 검증을 거쳐야 합니다. 여기에는 크게 두 가지 접근 방식이 있습니다:

토큰 인트로스펙션 (Token Introspection, RFC 7662): 서버가 인가 서버의 인트로스펙션 엔드포인트를 호출하여 토큰을 검증합니다. 인가 서버는 토큰의 현재 활성 상태(active/inactive)와 함께 연관된 클라이언트 ID, 스코프, 대상자(audience), 만료 시간, 주체(subject)를 반환합니다. 공식 MCP 예제에서 채택한 방식입니다. 토큰 검증마다 네트워크 호출이 필요하지만 토큰의 최신 상태를 확실하게 보장할 수 있습니다.

JWT 자체 검증 (JWT Validation): 토큰이 자체 포함형(self-contained) JWT인 경우, 서버는 서명, 발급자(issuer), 대상자(audience), 만료 시간, 스코프를 직접 확인하여 로컬에서 검증할 수 있습니다. 네트워크 호출이 없어 속도가 빠르지만, 토큰이 만료되기 전까지는 즉각적인 폐기(revocation) 여부를 감지할 수 없습니다.

두 방식 모두에서 가장 핵심적인 검증은 바로 **대상자 검증(Audience Checking)**입니다. 서버는 토큰의 aud 클레임이 자신의 리소스 URL과 정확히 일치하는지 반드시 확인해야 합니다. 이는 서버가 다른 서비스를 위해 발급된 토큰을 받아 하위 시스템으로 전달하는 안티패턴인 ’토큰 패스스루’를 방지하는 유일하고도 결정적인 통제 장치입니다.

# Audience validation (Python SDK pattern)
def _validate_resource(self, token_data: dict) -> bool:
    aud = token_data.get("aud")
    if isinstance(aud, list):
        return any(self._is_valid_resource(a) for a in aud)
    if isinstance(aud, str):
        return self._is_valid_resource(aud)
    return False

대상자가 일치하지 않는다면 토큰은 예외 없이 즉각 거부되어야 합니다. 이는 단순한 권장 사항이 아닙니다. MCP 인가 명세서는 토큰 패스스루를 명시적으로 엄격히 금지하고 있습니다.

11가지 공격 벡터 (The 11 Attack Vectors)

MCP 보안 모범 사례 명세서는 11가지 고유한 공격 유형을 규정하고 있습니다. 각각의 실제 위험과 필수 대응책은 다음과 같습니다.

1. 대리인 혼동(Confused Deputy) 공격

명세서에서 가장 높은 위험도(Highest-severity)로 분류된 공격입니다. MCP 클라이언트와 서드파티 API를 중계하는 MCP 프록시 서버를 대상으로 합니다.

프록시 서버는 서드파티 인가 서버에 대해 정적(static) 클라이언트 ID를 사용합니다. 사용자가 한 번 인증을 마치면, 서드파티 인가 서버는 동의 쿠키(consent cookie)를 설정합니다. 이후 공격자는 자신이 제어하는 redirect_uri를 가진 악성 MCP 클라이언트를 동적으로 등록(DCR)한 뒤, 사용자에게 정교하게 조작된 링크를 전송합니다. 사용자의 브라우저에는 유효한 동의 쿠키가 남아 있으므로 서드파티 서버는 동의 화면을 건너뛰고, 결국 인가 코드(authorization code)가 공격자에게 그대로 전달됩니다.

대응책(Countermeasure): MCP 프록시는 서드파티 인가 흐름으로 요청을 전달하기 전에 반드시 자체적인 클라이언트별 동의 화면을 구현해야 합니다. 동의 내역은 client_id별로 서버 측에 저장되어야 하며, CSRF 보호, 클릭재킹 방지, 정확한 리디렉션 URI 매칭(exact redirect URI matching)이 적용되어야 합니다. 또한 OAuth state 파라미터는 동의 승인 이전이 아니라 반드시 동의 승인 이후에 설정되어야 합니다.

2. 토큰 패스스루(Token Passthrough)

MCP 서버가 자신을 위해 발급되지 않은 토큰을 수락하고 이를 하위(downstream) API로 전달하는 취약점입니다. 이는 OAuth 신뢰 경계(trust boundary)를 무너뜨리고, 보안 제어 장치를 우회하며, 감사 추적을 오염시키고, 공격자의 내부 수평 이동(lateral movement)을 가능하게 합니다.

대응책(Countermeasure): 항상 대상자(aud, audience) 클레임을 검증하십시오. 자신의 MCP 서버용으로 명시적으로 발급되지 않은 토큰은 즉시 거부해야 합니다. 이는 어떠한 예외도 허용되지 않는 원칙입니다.

3. 서버 측 요청 위조(SSRF, Server-Side Request Forgery)

악성 MCP 서버가 자신의 OAuth 메타데이터 URL을 내부 네트워크 주소—클라우드 메타데이터 서비스인 169.254.169.254, 사내 내부망 서비스인 192.168.x.x, 로컬 Redis 포트인 localhost:6379 등—로 설정합니다. 클라이언트는 탐색(discovery) 단계에서 아무런 의심 없이 이 URL들을 호출하게 됩니다.

대응책(Countermeasure): 프로덕션 환경에서는 반드시 HTTPS를 강제하십시오. 사설 IP 대역(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16)으로의 접근을 차단해야 합니다. 리디렉션 대상 URL 역시 동일한 제한 조건으로 검증하십시오. 서버 측 배포 환경에서는 이그레스 프록시(egress proxy)를 운용하고, DNS 확인(DNS resolution) 결과를 고정(pinning)하여 TOCTOU(Time-of-Check to Time-of-Use) 공격을 방지하십시오.

4. 상태 핸들 탈취(State Handle Hijacking)

MCP는 프로토콜 수준에서 상태를 유지하지 않는 스테이트리스(stateless) 구조입니다. 요청 간 상태 유지가 필요한 서버는 명시적인 핸들(장바구니 ID, 워크플로우 ID 등)을 발급하고 이를 툴의 인자(arguments)로 전달받습니다. 공격자가 다른 사용자의 핸들을 획득하거나 추측해내면 타인의 상태 데이터에 무단으로 접근할 수 있습니다.

대응책(Countermeasure): 암호학적으로 안전한 의사 난수 생성기(CSPRNG)를 사용하여 핸들을 생성하십시오. 서버 측에서 핸들을 인증된 사용자와 강하게 결합("<user_id>:<handle>")해야 합니다. 핸들을 소유하고 있다는 사실 자체를 결코 ’인증’으로 간주해서는 안 됩니다. 핸들에 적절한 만료 시간을 설정하십시오.

5. 로컬 MCP 서버 침해(Local MCP Server Compromise)

클라이언트 설정 파일에 내장된 악성 시작 명령어, 서버 바이너리 내부에 숨겨진 악성 페이로드, 취약한 로컬호스트 서버를 겨냥한 DNS 리바인딩(DNS rebinding) 공격 등이 여기에 해당합니다.

대응책(Countermeasure): 로컬 서버에 연결하기 전 반드시 사용자 동의 대화상자를 표시하십시오. 실행될 정확한 명령어를 보여주고 위험한 패턴을 강조해야 합니다. 실행 환경을 샌드박싱(sandboxing)하십시오. localhost에서 HTTP 트랜스포트를 사용할 경우 인증 토큰을 의무화하거나 Unix 도메인 소켓을 사용하는 것이 안전합니다.

6. OAuth 인가 URL 주입(OAuth Authorization URL Injection)

악성 MCP 서버가 인가 엔드포인트로 javascript: URL을 제공합니다. 클라이언트가 이를 브라우저에서 실행하면 크로스 사이트 스크립팅(XSS)이 발생합니다. 또는 URL에 셸 메타문자가 포함되어 있고 클라이언트가 브라우저 실행을 위해 cmd.exe나 sh를 호출한다면 원격 코드 실행(RCE)으로 이어질 수 있습니다.

대응책(Countermeasure): http:// 및 https:// 스킴만 허용 목록(allowlist)으로 관리하십시오. javascript:, data:, file:, vbscript: 스킴은 즉시 거부해야 합니다. 브라우저로 URL을 열 때 절대 셸 명령어를 거쳐 실행하지 마십시오. 콘텐츠 보안 정책(CSP) 헤더를 엄격히 적용하십시오.

7. stdio 트랜스포트 권한 상승(stdio Transport Privilege Escalation)

프록시 아키텍처 환경에서 클라이언트 측 XSS 취약점은 시스템 전체의 권한 침해로 에스컬레이션될 수 있습니다. 공격자는 프록시 인증 토큰을 탈취한 후 로컬 MCP 프록시에 인증된 요청을 전송하여 stdio를 통해 임의의 명령어를 실행할 수 있습니다.

대응책(Countermeasure): XSS 발생을 원천 차단하십시오(6번 항목 참조). 생성되는 자식 프로세스를 철저히 샌드박싱하십시오. 파일시스템 접근 권한을 제한하십시오. 모든 stdio 사용 이력을 로깅하고, 프록시 통신을 격리된 별도의 보안 컨텍스트(security context) 내에서 운영하십시오.

8. 믹스업 공격(Mix-Up Attacks)

한 인가 서버를 장악한 공격자가 클라이언트를 속여, 정상적인 다른 인가 서버가 발급한 인가 코드를 공격자의 서버로 전송하도록 유도하는 공격입니다.

대응책(Countermeasure): 인가 응답 검증(Authorization Response Validation)을 적용하십시오. 리디렉션 전에 기록해 둔 인가 서버 정보와 응답을 반드시 바인딩해야 합니다. PKCE만으로는 이 공격을 막을 수 없으며, 리소스 지시자(Resource Indicators) 역시 해결책이 되지 못합니다. 이 공격을 방어하려면 신뢰할 수 있는 정상 서버들이 응답에 iss(발급자) 파라미터를 반드시 포함하여 발행해야 합니다.

9. Localhost 리디렉션 URI 사칭(Localhost Redirect URI Impersonation)

공격자가 정상적인 클라이언트의 메타데이터 URL을 client_id로 제출하고, 임의의 로컬호스트 포트를 redirect_uri로 바인딩하여 합법적인 클라이언트인 것처럼 위장합니다. 인가 서버는 정상적인 메타데이터를 확인하고 사용자에게도 합법적인 클라이언트 이름이 표시되지만, 인가 코드는 공격자의 포트로 전송됩니다.

대응책(Countermeasure): 인가 서버는 localhost 전용 리디렉션 URI에 대해 추가적인 경고 메시지를 표시하고, 사용자 동의 화면에서 리디렉션 URI의 전체 호스트명을 명확히 노출해야 합니다.

10. CIMD 신뢰 정책 악용(CIMD Trust Policy Exploitation)

클라이언트 ID 메타데이터 문서(Client ID Metadata Documents, CIMD)를 수락하는 인가 서버에는 도메인 기반의 신뢰 정책(trust policy)이 필수적입니다. 이러한 정책이 없으면 악의적인 임의의 도메인이 어떠한 클라이언트 신원으로도 등록할 수 있게 됩니다.

대응책(Countermeasure): 신뢰할 수 있는 도메인에 대한 허용 목록(allowlist)을 구축하십시오. 알려지지 않은 도메인에 대해서는 평판(reputation) 조회를 수행하십시오. 도메인 생성 기간(domain age) 및 인증서 유효성을 검증하고, 피싱 공격을 방지하기 위해 사용자 동의 화면에서 CIMD 정보를 눈에 띄게 명확히 표시하십시오.

11. 스코프 과다 부여(Scope Inflation)

초기 연결 단계에서 광범위한 스코프(files:*, db:*, admin:* 등)를 일괄 부여하는 경우입니다. 토큰이 단 한 번이라도 탈취되면 공격자는 무관한 도구와 리소스 전반에 걸쳐 수평적 접근(lateral access) 권한을 획득하게 되며, 토큰을 폐기하면 모든 정상적인 기능까지 한꺼번에 중단됩니다.

대응책(Countermeasure): 점진적 최소 권한(least-privilege) 스코프 모델을 채택하십시오. 처음에는 최소한의 기본 스코프(mcp:tools-basic)로 시작합니다. 이후 권한이 필요한 작업이 처음 시도될 때, 타깃형 WWW-Authenticate 스코프 챌린지를 통해 단계적으로 권한을 승격(escalate)합니다. 서버는 전체 카탈로그가 아닌 필요한 정밀 스코프 챌린지만을 발행하고, 클라이언트는 이전에 부여받은 스코프와 새로 요청된 스코프의 합집합(union)을 누적 관리합니다.

언어별 구현 패턴 (Implementation Patterns by Language)

공식 MCP SDK들은 자체적인 인가 지원 기능을 내장하고 있습니다:

TypeScript: mcpAuthMetadataRouter()를 사용하여 PRM 문서 및 OAuth 메타데이터를 서빙합니다. 인트로스펙션 엔드포인트를 호출하는 커스텀 tokenVerifier와 함께 미들웨어로 requireBearerAuth()를 적용합니다. StreamableHTTPServerTransport가 세션 관리를 처리합니다.

Python: AuthSettings와 커스텀 TokenVerifier 구현체를 포함한 MCPServer 클래스를 사용합니다. 서버는 자동으로 PRM을 발행하고 올바른 헤더와 함께 401 응답을 반환하며, 모든 Bearer 토큰을 구현된 검증기로 전달합니다.

C#: ASP.NET Core의 빌더 패턴을 기반으로 JWT 검증을 위해 AddJwtBearer()를 사용하고, MCP 전용 인증 메타데이터 처리를 위해 .AddMcp()를 연동합니다. 엔드포인트 보호에는 MapMcp().RequireAuthorization()을 적용합니다.

세 가지 접근 방식 모두 메타데이터 탐색 엔드포인트, 토큰 검증 미들웨어, 대상자(Audience) 검증이라는 동일한 아키텍처를 공유합니다. SDK는 프로토콜 수준의 세부 사항을 처리하며, 엔지니어는 토큰 검증 로직을 구현하고 인가 서버와의 연결을 설정하는 데 집중할 수 있습니다.

보안 태세 점검 체크리스트 (The Security Posture Checklist)

프로덕션 환경에 MCP 서버를 배포하는 팀을 위한 점검 항목:

결론 (The Bottom Line)

MCP의 인가 모델 자체는 결코 복잡하지 않습니다. 메타데이터 탐색 기능이 결합된 OAuth 2.1일 뿐입니다. 진정으로 복잡하고 위험한 것은 동적 클라이언트, 정적 프록시 신원, 멀티테넌트 인가 서버, 그리고 LLM 기반 도구 호출이 교차하면서 발생하는 방대한 공격 표면(Attack Surface)입니다.

특히 대리인 혼동(Confused Deputy) 공격은 모든 아키텍트가 밤잠을 설쳐야 할 만큼 치명적입니다. 암호화를 해독하거나 제로데이 취약점을 찾을 필요도 없이, 브라우저 쿠키와 교묘하게 조작된 링크 하나만으로 성공할 수 있기 때문입니다.

해결책은 더 복잡하고 화려한 인증 기술을 도입하는 것이 아닙니다. 클라이언트별, 스코프별로 엄격하게 동의를 관리하고, 정확한 리디렉션 URI 매칭 및 state 파라미터 검증을 수행하는 철저한 원칙 준수에 있습니다. 서드파티 인가 흐름으로 넘어가기 전 MCP 프록시 단계에 자체 동의 화면을 반드시 구축하십시오. 모든 토큰의 대상자(audience)를 한 번도 빠짐없이 검증하십시오. 메타데이터 탐색 요청에서 사설 IP 대역을 원천 차단하십시오. 그리고 누구를 위해 발급되었는지 확인되지 않은 토큰은 절대로 그대로 통과시키지 마십시오.

명세서는 프레임워크를 제공하고, 공격 벡터는 보안의 동기를 부여하며, 체크리스트는 나아갈 길을 제시합니다. 원칙에 입각하여 안전하게 구축하십시오.

출처: MCP Authorization Specification 및 Security Best Practices — MCP 2026-07-28 개정판.

연구 노트: [[MCP Authorization and Security Best Practices 2026]]

GxPChat