권한 제어와 API 연동

모든 조건이 충족될 때만 허용

인증된 행위자와 테넌트, 요청 작업, 레코드, 권한 유효성을 확인합니다. 필요한 조건이 없으면 기본적으로 거부합니다.

행위자

인증된 서비스 또는 파트너. 요청 본문의 client_id를 신뢰하지 않습니다.

레코드

인증된 tenant_id로 레코드를 제한합니다.

작업과 목적

shipping.address.read 등의 권한과 연결된 배송 목적을 확인합니다.

추가 조건

수신자, 만료, 취소, 이용 횟수, 개인과의 관계를 확인합니다.

일관된 권한 결정

권한 확인, 조회, 이용 횟수 갱신 사이의 상태 변화를 고려합니다.

서비스 인증과 자격 증명

Microsoft Entra 애플리케이션 Bearer token을 사용합니다. Azure에서는 Managed Identity, 인증서 방식에서는 개인 키로 앱을 인증해 토큰을 받습니다. 통신 경로의 mTLS 인증이 아닙니다. 현재 Vault는 하나의 Entra 디렉터리를 신뢰하며 다른 조직을 자동 지원하지 않습니다. 자격 증명은 백엔드에만 둡니다.

수신 대상 제한

토큰의 수신 대상과 목적지를 확인합니다. 다른 API용으로 발급된 토큰은 거부합니다.

자격 증명 교체

기존 자격 증명의 폐기와 전환 기간을 관리합니다.

브라우저와 서버 자격 증명 분리

서버 자격 증명을 JavaScript나 HTML에 넣지 않습니다.

오류, 재시도, 감사

다른 테넌트 기록이나 개인정보를 드러내지 않고 내부에 거부 사유를 남깁니다. 타임아웃으로 결과가 불확실하면 무작정 재시도하지 않고 멱등 키나 상태 조회를 사용합니다.

401 / 403

인증 누락과 권한 부족을 구별합니다. 상세 내용은 보호된 내부 로그에 기록합니다.

404

존재하지 않는 레코드와 권한 없는 레코드에 구별 불가능한 응답을 고려합니다.

409 / 429

멱등성 충돌과 호출 제한. 재시도 정책과 대기 시간을 정합니다.

503

권한이나 취소 상태를 확인할 수 없으면 허용으로 간주하지 않고 처리를 중단합니다.

DATA / INTEGRATION EXAMPLE

데이터 및 연동 예시

설계를 설명하는 예시입니다. 필드명과 값은 설명용이며 실행 가능한 API 명세가 아닙니다.

{
  "operation": "Authorization inputs and decision example",
  "authenticated_context": {
    "tenant_id": "tenant_a",
    "client_id": "carrier-a"
  },
  "request": {
    "action": "shipping.address.read",
    "resource_ref": "order_example_01",
    "purpose": "fulfillment"
  },
  "decision": {
    "allowed": true,
    "fields": [
      "postal_code",
      "address",
      "recipient_name"
    ],
    "decision_id": "dec_example_01"
  }
}

검증된 자격 증명으로 인증 문맥을 구성합니다. 클라이언트가 보낸 tenant_id를 권한 근거로 사용하지 않습니다.

관련 기술 설계

업무에 맞춘 연동 설계.

보유 데이터, 파트너, 필요한 작업을 정리해 노출을 줄일 방법을 찾습니다.