인증

핵심 요약

MCP마다 인증 방식이 다릅니다. 로컬 보호는 워크스페이스 제약, 원격 Gateway는 Bearer 토큰, Rust 로컬 커머스는 개발용 자격증명을 사용합니다.

개발용 사용자 헤더를 운영 환경에 사용하거나 공개 API에 판매자 토큰을 전달하지 마세요.

MCP 표면의 세 가지 서로 다른 자격 증명 메커니즘 — 서버별로 선택하고, 공개/비공개 경계를 절대 넘지 마세요.

한눈에 보기

서버	자격 증명	전달 방식
yp-mcp (로컬 protect)	없음 — 업스트림 API 없음	n/a (워크스페이스 경계 + approved:true가 게이트)
yetdapay-mcp-gateway (원격)	클라이언트의 Authorization: Bearer <token> 요청 헤더	셀러 범위 업스트림 엔드포인트로만 그대로 전달
yetdapay-mcp (Rust, 로컬)	env: YETDAPAY_MCP_TOKEN (bearer, 우선) 또는 YETDAPAY_DEV_USER (X-Dev-User 헤더)	서버 프로세스가 셀러 범위 요청에 첨부

공개/비공개 규칙 (모든 서버)

• 셀러 범위 도구는 자격 증명이 없으면 fail closed됩니다: 게이트웨이 → 어떤 업스트림 호출 전에 도구 오류 {code:"UNAUTHORIZED"}; Rust 서버 → 두 env var 모두 없으면 UNAUTHORIZED.
• 공개 도구와 모든 /public/** 업스트림 호출은 절대 자격 증명을 싣지 않습니다 — yetdapay_integration_assets_get과 yetdapay_license_verify는 공개 범위; 게이트웨이의 공개 요청 경로는 계약상 Authorization 헤더를 첨부하지 않습니다.
• 방문자 대면 코드에 임베드해도 안전한 것은 public_id(intpub_…)뿐 — 셀러 자격 증명이나 내부 id는 절대 안 됩니다.

Bearer 토큰 vs dev-user

두 백엔드가 다르기 때문에 두 가지 업스트림 인증 모드가 존재합니다:

백엔드	로그인 반환	CLI/MCP가 보내는 자격 증명
be-cloudflare Worker	{ok, token(JWT), …}	Authorization: Bearer <jwt>
be/ Axum	{ok, role, …} — 토큰 없음	X-Dev-User: <email> (dev-auth 배포만)

게이트웨이는 클라이언트가 보낸 헤더를 그대로 전달합니다 — Axum 백엔드를 가리키면 Authorization: Bearer는 dev 아이덴티티를 인증하지 않습니다; 로컬에서는 X-Dev-User 스타일 배포를 사용하거나 YETDAPAY_DEV_USER로 Rust 서버를 경유하세요. 프로덕션 백엔드는 X-Dev-User를 401로 거부합니다.

yp auth login은 이 분할을 자동으로 처리합니다: 백엔드가 실제로 반환한 것을 기반으로 {type:"bearer"} 또는 {type:"dev-user"}를 저장합니다 — CLI 설정 참조.

여기에 없는 것

• MCP 레이어에 PoP/entitlement 인증 없음. Entitlement/DPoP 헤더 쌍은 /licenses/{capability,execute,status}를 위한 바이어 디바이스 바인딩 플레인입니다 — MCP 서버가 아닌 라이선스 SDK가 처리합니다(디바이스 바인딩).
• 게이트웨이에 토큰 저장 없음. 게이트웨이는 무상태입니다 — 클라이언트가 자격 증명을 보유하고, 전달만 되며 절대 영속되지 않습니다.
• 자격 증명 echo 없음. 시작 로그는 인증 모드를 출력하고 토큰은 절대 출력하지 않습니다; 도구 오류는 절대 자격 증명을 포함하지 않습니다.

완전성을 위한 PoP

라이선스 wire에 관한 한(SDK ↔ 백엔드, MCP 아님): 게이트된 호출은 Authorization: Entitlement <jws> + DPoP: <proof-jws>를 가지며, 여기서 증명은 htu/htm/iat/jti/h/jwk를 바인딩합니다. 상세: 활성화 및 계약 매트릭스.