권한 부여

권한 부여 (Authorization)

MCP가 트랜스포트 수준에서 제공하는 권한 부여(authorization) 기능을 설명하는 페이지예요. MCP 클라이언트가 리소스 소유자를 대신해 제한된 MCP 서버에 요청을 보낼 수 있게 해 주며, HTTP 기반 트랜스포트를 위한 인증 흐름을 정의해요.

출처: 문서

본문

소개 (Introduction)

목적과 범위 (Purpose and Scope)

Model Context Protocol은 트랜스포트 수준에서 권한 부여 기능을 제공해서, MCP 클라이언트가 리소스 소유자를 대신해 제한된 MCP 서버에 요청을 보낼 수 있게 해요. 이 사양은 HTTP 기반 트랜스포트를 위한 권한 부여 흐름을 정의해요.

프로토콜 요구사항 (Protocol Requirements)

권한 부여는 MCP 구현에게 OPTIONAL(선택)이에요. 지원할 때:

  • HTTP 기반 트랜스포트를 사용하는 구현은 SHOULD 이 사양을 준수해야 해요.
  • STDIO 트랜스포트를 사용하는 구현은 SHOULD NOT 이 사양을 따르고, 대신 환경에서 자격 증명을 가져와야 해요.
  • 대체 트랜스포트를 사용하는 구현은 MUST 자신의 프로토콜에 대한 확립된 보안 모범 사례를 따라야 해요.

표준 준수 (Standards Compliance)

이 인증 메커니즘은 아래 나열된 확립된 사양에 기반하지만, 보안과 상호운용성을 보장하면서 단순함을 유지하기 위해 그 기능의 선택된 부분집합만 구현해요:

역할 (Roles)

보호된 MCP 서버는 OAuth 2.1 리소스 서버로 동작하며, 접근 토큰을 사용해 보호된 리소스 요청을 수락하고 응답할 수 있어요.

MCP 클라이언트는 OAuth 2.1 클라이언트로 동작하며, 리소스 소유자를 대신해 보호된 리소스 요청을 만들어요.

*authorization server(인증 서버)*는 (필요하면) 사용자와 상호작용하고 MCP 서버에서 사용할 접근 토큰을 발행할 책임이 있어요. 인증 서버의 구현 세부 사항은 이 사양의 범위를 벗어나요. 리소스 서버와 함께 호스팅되거나 별도 엔티티일 수 있어요. Authorization Server Discovery는 MCP 서버가 클라이언트에게 해당 인증 서버의 위치를 어떻게 나타내는지 지정해요.

개요 (Overview)

  1. 인증 서버는 MUST 기밀(confidential) 및 공개(public) 클라이언트 모두에 대해 적절한 보안 조치를 갖춘 OAuth 2.1을 구현해야 해요.

  2. 인증 서버와 MCP 클라이언트는 SHOULD OAuth Client ID Metadata Documents (draft-ietf-oauth-client-id-metadata-document-00)를 지원해야 해요.

  3. 인증 서버와 MCP 클라이언트는 MAY OAuth 2.0 Dynamic Client Registration Protocol (RFC7591)을 지원할 수 있어요. Dynamic Client Registration은 폐기되었고, Client ID Metadata Documents를 지원하지 않는 인증 서버와의 하위 호환성을 위해 유지된다는 점을 기억하세요.

  4. MCP 서버는 MUST OAuth 2.0 Protected Resource Metadata (RFC9728)를 구현해야 해요. MCP 클라이언트는 MUST authorization server discovery에 OAuth 2.0 Protected Resource Metadata를 사용해야 해요.

  5. MCP 인증 서버는 MUST 다음 발견 메커니즘 중 최소 하나를 제공해야 해요:

    MCP 클라이언트는 MUST 인증 서버와 상호작용하는 데 필요한 정보를 얻기 위해 두 발견 메커니즘을 모두 지원해야 해요.

Authorization Server Discovery

MCP 서버는 OAuth 2.0 Protected Resource Metadata를 통해 관련 인증 서버를 광고하고, MCP 클라이언트는 authorization server metadata discovery를 통해 인증 서버 엔드포인트와 지원 기능을 결정해요. 구현은 MUST Authorization Server Discovery에 정의된 규범적 발견 요구사항을 따라야 해요.

클라이언트 등록 (Client Registration)

권한 부여 흐름을 시작하기 전에 MCP 클라이언트는 MUST Client ID Metadata Documents, 사전 등록(pre-registration), 또는 Dynamic Client Registration의 세 등록 메커니즘 중 하나로 클라이언트 ID를 얻어야 해요. 요구사항과 선택 우선순위는 Client Registration에 정의돼 있어요.

범위 선택 전략 (Scope Selection Strategy)

MCP 서버는 SHOULD 리소스 접근에 필요한 범위(scopes)를 나타내기 위해 RFC 6750 Section 3에 정의된 대로 WWW-Authenticate 헤더에 scope 파라미터를 포함해야 해요. 이는 클라이언트에게 권한 부여 중 요청할 적절한 범위에 대한 즉각적인 안내를 제공하고, 최소 권한 원칙(least privilege)을 따르며 클라이언트가 과도한 권한을 요청하는 것을 방지해요.

WWW-Authenticate 도전(challenge)에 포함된 범위는 MAY scopes_supported와 일치하거나, 그 부분집합·상위집합이거나, 엄격한 부분집합도 상위집합도 아닌 대체 집합일 수 있어요. 클라이언트는 MUST NOT 도전된 범위 집합과 scopes_supported 사이에 특정 집합 관계를 가정해서는 안 돼요. 클라이언트는 MUST 도전에 제공된 범위를 현재 작업에 대한 권위 있는 것으로 취급해야 해요. 이 범위는 현재 요청을 충족하는 데 필요해요. 재권한 부여할 때 클라이언트는 SHOULD 다른 작업에 필요한 권한을 잃지 않도록 이미 부여된 범위와 함께 이 범위를 포함해야 해요 (Step-Up Authorization Flow 참조). 서버는 SHOULD 범위 집합을 구성하는 방식에 일관성을 유지하려 노력해야 하지만, 동적으로 발행된 모든 범위를 scopes_supported로 드러낼 필요는 없어요.

범위 안내가 있는 401 응답 예시:

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

권한 부여 흐름을 구현할 때 MCP 클라이언트는 SHOULD 의도한 작업에 필요한 범위만 요청함으로써 최소 권한 원칙을 따라야 해요. 초기 권한 부여 핸드셰이크 중 MCP 클라이언트는 SHOULD 범위 선택에 이 우선순위 순서를 따라야 해요:

  1. scope 파라미터 사용: 제공된다면 401 응답의 초기 WWW-Authenticate 헤더에서 가져온다
  2. scope가 없으면: Protected Resource Metadata 문서의 scopes_supported에 정의된 모든 범위를 사용하되, scopes_supported가 정의되지 않았으면 scope 파라미터를 생략한다

scopes_supported 필드는 기본 기능에 필요한 최소 범위 집합을 나타내기 위한 것이며 (Scope Minimization), 추가 범위는 Scope Challenge Handling 섹션에 설명된 step-up authorization flow 단계를 통해 점진적으로 요청돼요.

권한 부여 흐름 단계 (Authorization Flow Steps)

흐름에 표시된 등록 단계는 Client Registration에 정의된 메커니즘 중 하나를 사용해요.

전체 권한 부여 흐름은 다음과 같이 진행돼요:

sequenceDiagram
    participant B as User-Agent (Browser)
    participant C as Client
    participant M as MCP Server (Resource Server)
    participant A as Authorization Server

    C->>M: MCP request without token
    M->>C: HTTP 401 Unauthorized with WWW-Authenticate header
    Note over C: Extract resource_metadata URL from WWW-Authenticate

    C->>M: Request Protected Resource Metadata
    M->>C: Return metadata

    Note over C: Parse metadata and extract authorization server(s)<br/>Client determines AS to use

    C->>A: GET Authorization server metadata endpoint
    Note over C,A: Try OAuth 2.0 and OpenID Connect<br/>discovery endpoints in priority order
    A-->>C: Authorization server metadata

    alt Client ID Metadata Documents
        Note over C: Client uses HTTPS URL as client_id
        Note over A: Server detects URL-formatted client_id
        A->>C: Fetch metadata from client_id URL
        C-->>A: JSON metadata document
        Note over A: Validate metadata and redirect_uris
    else Dynamic client registration
        C->>A: POST /register
        A->>C: Client Credentials
    else Pre-registered client
        Note over C: Use existing client_id
    end

    Note over C: Generate PKCE parameters<br/>Include resource parameter<br/>Apply scope selection strategy<br/>Record expected issuer
    C->>B: Open browser with authorization URL + code_challenge + resource
    B->>A: Authorization request with resource parameter
    Note over A: User authorizes
    A->>B: Redirect to callback with authorization code + iss
    B->>C: Authorization code callback
    Note over C: Validate iss against recorded issuer (RFC 9207)
    C->>A: Token request + code_verifier + resource
    A->>C: Access token (+ refresh token)
    C->>M: MCP request with access token
    M-->>C: MCP response
    Note over C,M: MCP communication continues with valid token

권한 부여 응답 검증 (Authorization Response Validation)

사용자 에이전트를 리다이렉트하기 전에 클라이언트는 MUST 선택된 인증 서버의 검증된 메타데이터 문서에서 issuer 값을 기록하고(Authorization Server Metadata Discovery 참조), 이를 PKCE 코드 검증자(및 사용된다면 state 값)를 저장하는 데 쓰는 것과 같은 요청별 기록과 연관시켜야 해요. 이 섹션의 검증은 그 기록된 값이 진짜라는 것에 의존해요. 기대되는 issuer가 검증되지 않은 소스에서 얻었다면 아무 보호도 제공하지 않아요.

MCP 인증 서버는 SHOULD RFC9207 Section 2에 정의된 대로 오류 응답을 포함한 권한 부여 응답에 iss 파라미터를 포함해야 해요. iss 파라미터를 포함하는 인증 서버는 MUST 메타데이터에서 authorization_response_iss_parameter_supported를 true로 설정해 이를 광고해야 해요 (RFC9207 Section 2.3).

권한 부여 응답을 받으면, MCP 클라이언트는 MUST 인증 코드를 어떤 토큰 엔드포인트로도 전송하기 전에 RFC9207 Section 2.4의 검증을 적용해야 해요:

authorization_response_iss_parameter_supported iss in response Client action
true present Compare to the recorded issuer using simple string comparison (RFC3986 Section 6.2.1)
true absent Reject the response
false or absent present Compare to the recorded issuer using simple string comparison (RFC3986 Section 6.2.1)
false or absent absent Proceed

세 번째 행은 RFC9207 Section 2.4의 로컬 정책 조항을 적용해요: 이 사양은 메타데이터 광고와 무관하게 있는 그대로의 iss를 기록된 issuer와 비교하는데, 이는 메타데이터를 업데이트하기 전에 iss를 내보내는 인증 서버를 수용하기 위해서예요.

이 사양의 향후 개정은 인증 서버가 iss를 포함하는 것을 SHOULD에서 MUST로 격상할 것으로 예상돼요. 구현자는 지금 iss를 내보내고 검증하도록 권장돼요. iss 부재에 대한 클라이언트 거부 동작은 그 개정이 업그레이드 경로를 정의할 때까지 계속 authorization_response_iss_parameter_supported에 기반할 거예요.

RFC 9207 Section 2.4에 따라 application/x-www-form-urlencoded 응답에서 iss 값을 디코딩한 후, 클라이언트는 MUST NOT 비교 전에 스킴이나 호스트 대소문자 접기, 기본 포트 생략, 후행 슬래시, 퍼센트 인코딩 정규화(RFC 3986 Sections 6.2.2-6.2.3)를 적용해서는 안 돼요.

이 검증은 오류 응답에도 동일하게 적용돼요. 불일치 시 클라이언트는 MUST NOT error, error_description, error_uri에 대해 행동하거나 표시해서는 안 돼요.

리소스 파라미터 구현 (Resource Parameter Implementation)

MCP 클라이언트는 MUST RFC 8707에 정의된 OAuth 2.0용 Resource Indicators를 구현해 토큰이 요청되는 대상 리소스를 명시적으로 지정해야 해요. resource 파라미터:

  1. MUST 권한 부여 요청과 토큰 요청 둘 다에 포함되어야 한다.
  2. MUST 클라이언트가 토큰을 사용할 의도인 MCP 서버를 식별해야 한다.
  3. MUST RFC 8707 Section 2에 정의된 MCP 서버의 정규 URI를 사용해야 한다.

정규 서버 URI (Canonical Server URI)

이 사양의 목적상, MCP 서버의 정규 URI는 RFC 8707 Section 2에 지정된 리소스 식별자로 정의되며 RFC 9728의 resource 파라미터와 정렬돼요.

MCP 클라이언트는 SHOULD 접근하려는 MCP 서버에 대해 가장 구체적인 URI를 제공해야 해요. RFC 8707의 안내를 따르며. 정규 형식이 소문자 스킴과 호스트 구성 요소를 사용하지만, 구현은 SHOULD 견고성과 상호운용성을 위해 대문자 스킴과 호스트 구성 요소도 수용해야 해요.

유효한 정규 URI의 예시:

  • https://mcp.example.com/mcp
  • https://mcp.example.com
  • https://mcp.example.com:8443
  • https://mcp.example.com/server/mcp (개별 MCP 서버를 식별하기 위해 경로 구성 요소가 필요할 때)

유효하지 않은 정규 URI의 예시:

  • mcp.example.com (스킴 누락)
  • https://mcp.example.com#fragment (프래그먼트 포함)

참고: https://mcp.example.com/(후행 슬래시 있음)과 https://mcp.example.com(후행 슬래시 없음) 둘 다 RFC 3986에 따르면 기술적으로 유효한 절대 URI이지만, 구현은 특정 리소스에 후행 슬래시가 의미적으로 중요하지 않다면 더 나은 상호운용성을 위해 후행 슬래시 없는 형식을 일관되게 사용해야 SHOULD 해요.

예를 들어, https://mcp.example.com의 MCP 서버에 접근한다면 권한 부여 요청은 다음을 포함해요:

&resource=https%3A%2F%2Fmcp.example.com

MCP 클라이언트는 MUST 인증 서버가 지원하는지 여부와 무관하게 이 파라미터를 보내야 해요.

접근 토큰 사용 (Access Token Usage)

토큰 요구사항 (Token Requirements)

MCP 서버에 요청할 때 접근 토큰 처리는 MUST OAuth 2.1 Section 5 "Resource Requests"에 정의된 요구사항을 준수해야 해요. 구체적으로:

  1. MCP 클라이언트는 MUST OAuth 2.1 Section 5.1.1에 정의된 Authorization 요청 헤더 필드를 사용해야 해요:
Authorization: Bearer ***

권한 부여가 클라이언트에서 서버로 가는 모든 HTTP 요청에 포함되어야 MUST 한다는 점을 기억하세요.

  1. 접근 토큰은 MUST NOT URI 쿼리 문자열에 포함되지 말아야 해요

예시 요청:

GET /mcp HTTP/1.1
Host: mcp.example.com
Authorization: Bearer eyJhbG...s...

토큰 처리 (Token Handling)

OAuth 2.1 리소스 서버 역할을 하는 MCP 서버는 MUST OAuth 2.1 Section 5.2에 설명된 대로 접근 토큰을 검증해야 해요. MCP 서버는 MUST 접근 토큰이 RFC 8707 Section 2에 따라 의도된 수신자(audience)로 자신을 위해 특별히 발행되었는지 검증해야 해요. 검증이 실패하면 서버는 MUST OAuth 2.1 Section 5.3 오류 처리 요구사항에 따라 응답해야 해요. 유효하지 않거나 만료된 토큰은 MUST HTTP 401 응답을 받아야 해요.

MCP 클라이언트는 MUST NOT MCP 서버의 인증 서버가 발행한 토큰 외의 토큰을 MCP 서버에 보내서는 안 돼요.

MCP 서버는 MUST 자신의 리소스에 사용하기에 유효한 토큰만 수락해야 해요.

MCP 서버는 MUST NOT 다른 토큰을 수락하거나 전달해서는 안 돼요.

리프레시 토큰 (Refresh Tokens)

이 섹션은 OAuth와 OpenID Connect 모두에서 리프레시 토큰을 처리하거나 발행할 때 MCP 클라이언트와 MCP 서버를 위한 지침을 제공해요.

리프레시 토큰을 원하는 MCP 클라이언트는:

  • MUST OAuth 2.1 Section 4.3에 지정된 대로 전송과 저장에서 리프레시 토큰을 기밀로 유지해야 한다
  • SHOULD 클라이언트 메타데이터의 grant_types에 refresh_token을 포함해야 한다
  • MAY Authorization Server 메타데이터가 scopes_supported에 포함할 때 권한 부여 및 토큰 요청의 scope 파라미터에 offline_access를 추가할 수 있다
  • MUST NOT 리프레시 토큰이 발행될 것이라 가정해서는 안 된다. AS는 재량권을 유지한다

MCP 서버 (Protected Resources)는 SHOULD NOT WWW-Authenticate scope나 Protected Resource Metadata scopes_supported에 offline_access를 포함하지 말아야 한다. 리프레시 토큰은 리소스 요구사항이 아니기 때문이다.

오류 처리 (Error Handling)

서버는 MUST 인증 오류에 대해 적절한 HTTP 상태 코드를 반환해야 해요:

Status Code Description Usage
401 Unauthorized Authorization required or token invalid
403 Forbidden Invalid scopes or insufficient permissions
400 Bad Request Malformed authorization request

범위 도전 처리 (Scope Challenge Handling)

이 섹션은 클라이언트가 이미 토큰을 갖고 있지만 추가 권한이 필요할 때, 런타임 작업 중 불충분한 범위 오류를 처리하는 방법을 다뤄요. 이는 OAuth 2.1 Section 5에 정의된 오류 처리 패턴을 따르고 RFC 9728 (OAuth 2.0 Protected Resource Metadata)의 메타데이터 필드를 활용해요.

런타임 불충분 범위 오류 (Runtime Insufficient Scope Errors)

런타임 작업 중 클라이언트가 범위가 불충분한 접근 토큰으로 요청하면, 서버는 SHOULD 다음으로 응답해야 해요:

  • HTTP 403 Forbidden 상태 코드 (RFC 6750 Section 3.1에 따름)
  • Bearer 스킴과 추가 파라미터가 있는 WWW-Authenticate 헤더:
    • error="insufficient_scope" - 권한 부여 실패의 구체적 유형을 나타냄
    • scope="required_scope1 required_scope2" - 작업에 필요한 최소 범위를 지정
    • resource_metadata - Protected Resource Metadata 문서의 URI (401 응답과 일관성 유지용)
    • error_description (선택) - 오류에 대한 사람이 읽을 수 있는 설명

서버 범위 관리: 불충분 범위 오류로 응답할 때 서버는 SHOULD RFC 6750 Section 3.1과 일관되게 현재 작업을 충족하는 데 필요한 범위를 scope 파라미터에 포함해야 해요. scope 속성은 요청된 리소스에 접근하는 데 필요한 범위를 설명해요. 서버는 클라이언트가 이전에 부여받은 범위를 포함할 필요는 없어요.

서버가 어떤 범위 포함 전략을 채택하든, 서버는 SHOULD 단일 도전에 현재 작업에 필요한 모든 범위를 포함해야 해요. 점진적으로 도전하는 것(누락된 범위 하나를 반환했다가, 후속 재시도에서 또 다른 범위를 반환)은 단일 작업에 여러 권한 부여 왕복을 강제해 사용자 경험을 저하시켜요. 필수 범위는 특정 요청 인자와 컨텍스트에 따라 동적으로 결정될 수 있지만, 일단 결정되면 함께 내보내야 해요.

서버는 SHOULD 클라이언트에게 예측 가능한 동작을 제공하려고 범위 포함 전략에 일관성이 있어야 해요.

서버는 SHOULD 응답에 포함할 범위를 결정할 때 사용자 경험 영향을 고려해야 해요. 잘못 설정된 범위는 빈번한 사용자 상호작용을 요구할 수 있기 때문이다.

작업 전반의 범위 누적은 클라이언트 측 책임이에요. 범위 합집합 요구사항은 Step-Up Authorization Flow를 참조하세요.

불충분 범위 응답 예시:

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",
                         error_description="File write permission required for this operation"

Step-Up 권한 부여 흐름 (Step-Up Authorization Flow)

클라이언트는 초기 권한 부여 중이나 런타임에 범위 관련 오류(insufficient_scope)를 받게 돼요. 클라이언트는 SHOULD step-up authorization flow로 확장된 범위 집합을 가진 새 접근 토큰을 요청해 이 오류에 응답하거나, 다른 적절한 방식으로 오류를 처리해야 해요. 사용자를 대신해 행동하는 클라이언트는 SHOULD step-up authorization flow를 시도해야 해요. 스스로를 대신해 행동하는 클라이언트(client_credentials 클라이언트)는 MAY step-up authorization flow를 시도하거나 요청을 즉시 중단할 수 있어요.

흐름은 다음과 같아요:

  1. 오류 정보 파싱: 인증 서버 응답 또는 WWW-Authenticate 헤더에서 오류 정보를 파싱한다
  2. 필요한 범위 결정: 클라이언트가 이전에 요청한 범위 집합과 현재 도전의 범위의 합집합을 계산한다. 이는 서버가 RFC 6750 Section 3.1에 따라 작업별 범위 도전을 내보낼 때 이전에 부여된 권한이 보존되도록 보장한다. 클라이언트는 MAY 초기 범위 선택 안내를 위해 Scope Selection Strategy도 참조할 수 있다.
  3. 재권한 부여 시작: 결정된 범위 집합으로 (재)권한 부여를 시작한다
  4. 원래 요청 재시도: 새 권한 부여로 원래 요청을 기껏해야 몇 번 재시도하고, 이것을 영구 권한 부여 실패로 취급한다

클라이언트는 SHOULD 재시도 한도를 구현하고 SHOULD 같은 리소스와 작업 조합에 대한 반복 실패를 피하려고 범위 업그레이드 시도를 추적해야 해요.

서버는 MUST 더 넓은 범위가 더 좁은 범위를 의미하는 범위 계층(scopes hierarchies)을 고려해 토큰이 작업에 충분한지 결정해야 해요.

보안 고려 사항 (Security Considerations)

이 사양의 구현은 MUST Security Considerations의 규범적 보안 요구사항을 따라야 해요. 이는 토큰 audience 바인딩과 검증, 토큰 도난, 통신 보안, 인증 코드 보호, mix-up 및 confused deputy 공격, 오픈 리다이렉션, Client ID Metadata Document 보안을 다룬다.

MCP 권한 부여 확장 (MCP Authorization Extensions)

핵심 프로토콜에 대한 여러 권한 부여 확장이 추가 인증 메커니즘을 정의해요. 이 확장들은:

  • 선택적 (Optional) - 구현체는 이 확장을 채택할지 선택할 수 있음
  • 부가적 (Additive) - 확장은 핵심 프로토콜 기능을 수정하거나 깨지 않으며, 핵심 프로토콜 동작을 보존하면서 새 기능을 추가함
  • 조합 가능 (Composable) - 확장은 모듈형이며 충돌 없이 함께 작동하도록 설계되어, 구현체가 여러 확장을 동시에 채택할 수 있음
  • 독립적으로 버전 관리 (Versioned independently) - 확장은 핵심 MCP 버전 주기를 따르되 필요에 따라 독립 버전을 채택할 수 있음

지원되는 확장 목록은 MCP Authorization Extensions 저장소에서 찾을 수 있어요.

더 알아보기 (Learn more)