Authorization Server Discovery

MCP 서버가 관련 인증 서버(authorization server)를 MCP 클라이언트에게 광고하는 메커니즘과, 클라이언트가 인증 서버 엔드포인트와 지원 기능을 결정하는 발견(discovery) 과정을 설명하는 페이지예요.

출처: 문서

본문

이 문서는 MCP 서버가 관련 인증 서버를 MCP 클라이언트에게 광고하는 메커니즘과, MCP 클라이언트가 인증 서버 엔드포인트와 지원 기능을 결정할 수 있는 발견 과정을 설명해요.

Authorization Server 위치 (Authorization Server Location)

MCP 서버는 MUST 인증 서버의 위치를 나타내기 위해 OAuth 2.0 Protected Resource Metadata (RFC9728) 사양을 구현해야 해요. MCP 서버가 반환하는 Protected Resource Metadata 문서는 MUST 최소 하나의 인증 서버를 담은 authorization_servers 필드를 포함해야 해요.

authorization_servers의 구체적 사용은 이 사양의 범위를 벗어나요. 구현자는 구현 세부 사항 안내를 위해 OAuth 2.0 Protected Resource Metadata (RFC9728)를 참조해야 해요.

구현자는 Protected Resource Metadata 문서가 여러 인증 서버를 정의할 수 있다는 점에 주의해야 해요. 사용할 인증 서버를 선택하는 책임은 RFC9728 Section 7.6 "Authorization Servers"에 명시된 지침에 따라 MCP 클라이언트에 있어요.

authorization_servers에 여러 인증 서버가 나열되면, 각각은 독립적인 OAuth 2.0 인증 서버예요. RFC 6749 Section 2.2와 일관되게, 클라이언트 식별자는 이를 발행한 인증 서버에 고유해요. 클라이언트는 MUST 인증 서버별로 별도의 등록 상태(클라이언트 자격 증명, 토큰)를 유지하고 MUST NOT 한 인증 서버에 유효한 자격 증명이 다른 인증 서버에서 수락될 것이라 가정해서는 안 돼요. 클라이언트 자격 증명을 이를 발행한 인증 서버와 연관시키는 요구사항은 Authorization Server Binding을 참조하세요.

Protected Resource Metadata 발견 요구사항 (Protected Resource Metadata Discovery Requirements)

MCP 서버는 MUST MCP 클라이언트에게 인증 서버 위치 정보를 제공하기 위해 다음 발견 메커니즘 중 하나를 구현해야 해요:

WWW-Authenticate 헤더: 401 Unauthorized 응답을 반환할 때 RFC9728 Section 5.1에 설명된 대로 WWW-Authenticate HTTP 헤더의 resource_metadata 아래에 리소스 메타데이터 URL을 포함한다.
Well-Known URI: RFC9728에 지정된 대로 well-known URI에서 메타데이터를 제공한다. 다음 중 하나일 수 있다:
- 서버의 MCP 엔드포인트 경로: https://example.com/public/mcp는 https://example.com/.well-known/oauth-protected-resource/public/mcp에서 메타데이터를 호스팅할 수 있다
- 루트에서: https://example.com/.well-known/oauth-protected-resource

MCP 클라이언트는 MUST 두 발견 메커니즘을 모두 지원하고, 존재할 때 파싱된 WWW-Authenticate 헤더의 리소스 메타데이터 URL을 사용해야 해요. 그렇지 않으면 MUST 위에 나열된 순서로 well-known URI를 구성하고 요청하는 폴백을 해야 해요.

MCP 클라이언트는 MUST WWW-Authenticate 헤더를 파싱하고 MCP 서버의 HTTP 401 Unauthorized 응답에 적절히 응답할 수 있어야 해요.

서버는 또한 리소스 접근에 필요한 범위를 나타내기 위해 WWW-Authenticate 도전에 scope 파라미터를 포함할 수 있어요. 범위 의미론과 관련 클라이언트 동작은 Scope Selection Strategy 섹션에 정의돼 있어요.

Authorization Server Metadata 발견 (Authorization Server Metadata Discovery)

MCP는 authorization server metadata 발견을 위해 RFC 8414 Section 3.1에 정의된 기본 oauth-authorization-server well-known URI 접미사를 사용해요. MCP는 애플리케이션 특정 well-known URI 접미사를 정의하지 않아요.

다양한 issuer URL 형식을 처리하고 OAuth 2.0 Authorization Server Metadata와 OpenID Connect Discovery 1.0 사양 모두와 상호운용성을 보장하기 위해, MCP 클라이언트는 MUST authorization server metadata를 발견할 때 여러 well-known 엔드포인트를 시도해야 해요.

발견 접근 방식은 OAuth 2.0 Authorization Server Metadata 발견을 위한 RFC 8414 Section 3.1 "Authorization Server Metadata Request"와 OpenID Connect Discovery 1.0 상호운용성을 위한 RFC 8414 Section 5 "Compatibility Notes"에 기반해요.

경로 구성 요소가 있는 issuer URL(예: https://auth.example.com/tenant1)의 경우, 클라이언트는 MUST 다음 우선순위 순서로 엔드포인트를 시도해야 해요:

경로 삽입이 있는 OAuth 2.0 Authorization Server Metadata: https://auth.example.com/.well-known/oauth-authorization-server/tenant1
경로 삽입이 있는 OpenID Connect Discovery 1.0: https://auth.example.com/.well-known/openid-configuration/tenant1
경로 추가가 있는 OpenID Connect Discovery 1.0: https://auth.example.com/tenant1/.well-known/openid-configuration

경로 구성 요소가 없는 issuer URL(예: https://auth.example.com)의 경우, 클라이언트는 MUST 시도해야 해요:

OAuth 2.0 Authorization Server Metadata: https://auth.example.com/.well-known/oauth-authorization-server
OpenID Connect Discovery 1.0: https://auth.example.com/.well-known/openid-configuration

메타데이터 문서를 검색한 후, MCP 클라이언트는 MUST RFC8414 Section 3.3 또는 OpenID Connect Discovery Section 4.3이 요구하는 대로 이를 검증해야 해요. 문서의 issuer 값은 MUST well-known URL을 구성하는 데 사용된 issuer 식별자와 동일해야 해요. 다르면 클라이언트는 MUST NOT 그 메타데이터를 사용해서는 안 돼요. 예를 들어 https://attacker.example/.well-known/oauth-authorization-server에서 가져왔는데 "issuer": "https://honest.example"를 담은 문서는 MUST 거부되어야 해요.

시퀀스 다이어그램 (Sequence Diagram)

다음 다이어그램은 예시 흐름을 개괄해요:

sequenceDiagram
    participant C as Client
    participant M as MCP Server (Resource Server)
    participant A as Authorization Server

    Note over C: Attempt unauthenticated MCP request
    C->>M: MCP request without token
    M-->>C: HTTP 401 Unauthorized (may include WWW-Authenticate header)

    alt Header includes resource_metadata
        Note over C: Extract resource_metadata URL from header
        C->>M: GET resource_metadata URI
        M-->>C: Resource metadata with authorization server URL
    else No resource_metadata in header
        Note over C: Fallback to well-known URI probing
        Note over M: _Not applicable if the MCP server is at the root_
        C->>M: GET /.well-known/oauth-protected-resource/mcp
        alt Sub-path metadata found
            M-->>C: Resource metadata with authorization server URL
        else Sub-path not found
            C->>M: GET /.well-known/oauth-protected-resource
            alt Root metadata found
                M-->>C: Resource metadata with authorization server URL
            else Root metadata not found
                Note over C: Abort or use pre-configured values
            end
        end
    end

    Note over C: Validate RS metadata,<br />build AS metadata URL

    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

    Note over C,A: OAuth 2.1 authorization flow happens here

    C->>A: Token request
    A-->>C: Access token

    C->>M: MCP request with access token
    M-->>C: MCP response
    Note over C,M: MCP communication continues with valid token

Authorization Server Discovery