MCP 비-OAuth 인증

MCP 비-OAuth 인증 (Non-OAuth Authentication)

이 페이지는 OAuth 흐름을 사용하지 않는 업스트림 MCP 인증(인증 없음, 고정 자격 증명, AWS SigV4)을 다뤄요. OAuth 설정은 MCP OAuth, MCP OAuth Passthrough, MCP On-Behalf-Of Auth를 참고해 주세요.

LiteLLM은 MCP 요청에 대해 두 개의 별도 인증 홉을 처리해요:

클라이언트 → LiteLLM: MCP 클라이언트가 LiteLLM 게이트웨이를 사용할 수 있음을 증명하며, 보통 LiteLLM API 키로 해요.
LiteLLM → 업스트림 MCP 서버: LiteLLM이 해당 서버의 auth_type에 따라 선택된 업스트림에 인증해요.

MCP 서버의 auth_type이 두 번째 홉을 제어해요. 게이트웨이 입장용으로 사용된 LiteLLM API 키는 업스트림 서버에 복사되지 않아요.

전송 범위 — 이 페이지의 와이어 예시는 SSE 또는 Streamable HTTP를 사용하는 원격 MCP 서버를 다뤄요. OpenAPI 생성 MCP 도구는 별도 auth 헤더 처리가 있어요.

출처: 문서

본문

비-OAuth 인증 타입 선택 (Choose a non-OAuth auth type)

고정된 비-OAuth 자격 증명에는 업스트림 서버가 요구하는 헤더와 일치하는 타입을 고르세요:

`auth_type`	제공하는 것	업스트림으로 보내는 기본 자격 증명	사용 사례
`none`	없음	자격 증명 없음	업스트림이 익명 요청을 허용하거나 네트워크 레벨 접근 제어에 의존
`api_key`	API 키 값	`X-API-Key: ***`	업스트림이 `X-API-Key` 헤더를 기대함
`bearer_token`	토큰만	`Authorization: Bearer ***`	고정 베어러 토큰, 개인용 액세스 토큰, 서비스 토큰
`basic`	원시 `username:password`	`Authorization: Basic <base6...)>`	HTTP Basic 인증
`token`	토큰만	`Authorization: token ***`	GitHub 스타일 `token` 스킴을 명시적으로 사용하는 업스트림
`authorization`	스킴 포함 완전한 헤더 값	`Authorization: ***`	사용자 지정 인증 스킴. config와 API에서 사용 가능
`aws_sigv4`	AWS 자격 증명 또는 IAM 역할	요청마다 새 AWS SigV4 서명	AWS Bedrock AgentCore MCP 서버

클라이언트가 보내는 것 (What the client sends)

정적 업스트림 자격 증명은 MCP 서버 구성에 저장돼요. 클라이언트는 매 도구 요청에 업스트림 사용자 이름, 비밀번호, API 키를 보내지 않아요.

예를 들어 클라이언트는 업스트림 서버가 none, basic, api_key 중 무엇을 쓰는지와 무관하게 같은 요청을 보낼 수 있어요:

클라이언트 → LiteLLM:

POST /inventory/mcp HTTP/1.1
Host: litellm.example.com
x-litellm-api-key: *** sk-litellm
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/list","params":{}}

LiteLLM이 클라이언트를 인증하고 inventory MCP 서버를 선택한 다음 그 서버의 auth_type으로 업스트림 요청을 구축해요. 다음 섹션들이 결과 업스트림 자격 증명을 보여줍니다.

클라이언트는 true_passthrough와 oauth_delegate에 대해서는 업스트림 토큰을 제공해요. MCP OAuth Passthrough 참고.

비-OAuth 인증 타입 (Non-OAuth auth types)

None

auth_type: none은 인증 해석기가 업스트림 자격 증명을 기여하지 않음을 의미해요.

동작: LiteLLM은 이 인증 타입에 Authorization, X-API-Key 또는 다른 자격 증명 헤더를 추가하지 않음.
사용 시점: 업스트림 MCP 엔드포인트가 애플리케이션 자격 증명을 요구하지 않을 때. 일반적인 예는 공용 MCP 서버 또는 네트워크 정책으로 보호되는 사설 엔드포인트.
사용하지 않을 때: 업스트림이 Basic Auth, API 키, 베어러 토큰, 호출자 소유 토큰을 요구할 때.

config.yaml:

mcp_servers:
  public_inventory:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: "none"

업스트림 요청은 LiteLLM이 추가한 인증 자격 증명이 없어요:

POST /mcp HTTP/1.1
Host: mcp.example.com
Content-Type: application/json

URL에 자격 증명을 넣지 마세요 — https://username:[email protected]/mcp 같은 URL은 auth_type이 none일 때 거부돼요. LiteLLM은 URL userinfo에서 Basic Auth를 추론하지 않아요. URL에서 자격 증명을 제거하고 auth_type: basic으로 구성하세요.

Basic Auth

auth_type: basic은 원시 사용자 이름과 비밀번호를 표준 HTTP Basic 헤더로 바꿔요.

인증 값: username:password 입력. base64 인코딩하지 말고 Basic 접두사도 넣지 마세요.
동작: LiteLLM이 전체 값을 base64 인코딩하고 Basic 스킴을 추가해 매 업스트림 요청에 같은 서비스 자격 증명을 보내요.
사용 시점: 업스트림 문서가 HTTP Basic 인증을 요구할 때.

config.yaml:

mcp_servers:
  inventory:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: "basic"
    auth_value: os.environ/MCP_BASIC_AUTH # value: username:password

MCP_BASIC_AUTH=username:password이면 LiteLLM이 다음을 보내요:

Authorization: Basic dXNlcm...cmQ=

사용자 이름과 비밀번호는 서버 URL이 아니라 auth_value에 있어야 해요.

API key

auth_type: api_key는 X-API-Key에 고정 키 하나를 보내요.

인증 값: 키 값만 입력.
동작: LiteLLM이 각 업스트림 요청에 같은 키를 보내요.
사용 시점: 업스트림 문서가 X-API-Key를 요구할 때.

config.yaml:

mcp_servers:
  inventory:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: "api_key"
    auth_value: os.environ/INVENTORY_API_KEY

업스트림:

X-API-Key: <INVEN...KEY>

업스트림이 다른 헤더 이름을 기대한다면 static_headers를 사용하거나 upstream_token_header를 설정하세요.

Bearer token

auth_type: bearer_token은 고정 토큰에 Bearer 스킴을 추가해요.

인증 값: 토큰만 입력. Bearer 접두사는 넣지 마세요.
동작: LiteLLM이 매 업스트림 요청에 Authorization: Bearer ***를 보내요.
사용 시점: 업스트림이 서비스 토큰이나 개인용 액세스 토큰 같은 고정 베어러 토큰을 받을 때. 발급·새로고침·교환·호출자 제공이 필요한 토큰은 MCP OAuth 참고.

config.yaml:

mcp_servers:
  inventory:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: "bearer_token"
    auth_value: os.environ/INVENTORY_TOKEN

업스트림:

Authorization: Bearer ***

Token

auth_type: token은 소문자 token authorization 스킴을 사용해요.

인증 값: 토큰만 입력. token 접두사는 넣지 마세요.
동작: LiteLLM이 Authorization: token ***를 보내요.
사용 시점: 업스트림이 이 스킴을 명시적으로 문서화할 때. 표준 베어러 인증에는 bearer_token을 사용하세요.

config.yaml:

mcp_servers:
  legacy_service:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: "token"
    auth_value: os.environ/LEGACY_SERVICE_TOKEN

업스트림:

Authorization: token <LEGAC...KEN>

Authorization

auth_type: authorization은 인증 값을 Authorization 헤더에 그대로 보내요.

인증 값: 스킴 또는 접두사 포함 완전한 값을 입력.
동작: LiteLLM이 스킴을 추가·제거·변경하지 않아요.
사용 시점: 업스트림이 다른 정적 타입으로 다루지 않는 authorization 스킴을 사용할 때. 이 값은 config.yaml과 서버 API에서 지원되지만 현재 Admin UI 선택기에는 나열되지 않아요.

config.yaml:

mcp_servers:
  custom_scheme:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: "authorization"
    auth_value: os.environ/CUSTOM_AUTH_HEADER # value: Custom <token>

업스트림:

Authorization: Custom <CUSTO...KEN>

AWS SigV4

auth_type: aws_sigv4는 고정 토큰 하나를 붙이는 대신 요청마다 AWS Signature Version 4로 서명해요.

동작: LiteLLM이 각 요청을 해시·서명한 다음 AWS가 요구하는 생성된 Authorization, x-amz-date, 임시 자격 증명 헤더를 추가해요.
사용 시점: 업스트림이 AWS Bedrock AgentCore MCP 서버일 때.
자격 증명 소스: 명시적 AWS 자격 증명, boto3 자격 증명 체인, 또는 LiteLLM이 가정할 수 있는 IAM 역할.

config.yaml:

mcp_servers:
  agentcore:
    url: "https://bedrock-agentcore.us-east-1.amazonaws.com/runtimes/<url-encoded-ARN>/invocations"
    transport: "http"
    auth_type: "aws_sigv4"
    aws_role_name: os.environ/AWS_ROLE_ARN
    aws_region_name: "us-east-1"
    aws_service_name: "bedrock-agentcore"

설정과 문제 해결은 MCP AWS SigV4 Auth 참고하세요.

사용자 지정 및 전달 헤더 (Custom and forwarded headers)

일부 업스트림은 사용자 지정 헤더 이름이나 둘 이상의 고정 헤더를 요구해요. 이 설정들은 auth_type과 별개예요:

static_headers: LiteLLM이 구성된 값을 모든 업스트림 요청에 추가해요. 사용자 지정 정적 자격 증명, 테넌트 식별자, 보조 게이트웨이 자격 증명에 사용.
extra_headers: LiteLLM이 현재 클라이언트 요청에서 이름이 지정된 헤더만 업스트림으로 복사해요. 클라이언트가 소유한 요청별 컨텍스트에 사용.

config.yaml:

mcp_servers:
  custom_headers:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: "none"
    static_headers:
      X-Custom-Auth: os.environ/MCP_CUSTOM_AUTH
    extra_headers:
      - X-Tenant-ID

이 예시에서 none 해석기는 여전히 자격 증명을 기여하지 않아요. X-Custom-Auth는 static_headers에서 별도로 선언되었기 때문에 존재해요.

호출자 소유 OAuth 베어러가 Authorization에 있다면 일반 추가 헤더로 취급하지 말고 true_passthrough 또는 oauth_delegate를 사용하세요.

더 알아보기 (Learn more)

MCP OAuth — 업스트림 OAuth2 설정
MCP OAuth Passthrough — 패스스루 OAuth
MCP AWS SigV4 — AWS 서명 요청