741 VIEWS
핀터레스트 링크드인 LINE

어쩐지 시간이 지나 버려, 더 이상 기억이 흐려지고 있습니다만… .

概要

일본 시간 7월 25일, IETF 123 Madrid에서 OAuth WG의 제2 세션이 행해졌습니다.사전에 발표된 아젠다는 다음과 같습니다.

다음은 주요 테마, 중요한 아이디어 및 사실을 요약한 것입니다.

1. 토큰 상태 목록(Token Status List)

  • 확장 가능한 해지 메커니즘: 토큰 상태 목록은 확장 가능한 해지 메커니즘으로 설계되었으며 프라이버시 특성, 이해 편의성 및 구현 용이성에 중점을 둡니다.
  • 광범위한 참조 및 테스트: 현재 ISO mDL , mDOC에서 참조되고 있으며 유럽의 ARF에서도 상태 메커니즘 중 하나로 언급되어 있습니다.
  • 확장점 및 레지스트리 설정: 본 초안은 단일 메커니즘에 그치지 않고 상태 메커니즘 전반의 확장점과 레지스트리를 확립합니다.
  • 주요 변경 사항:
    • 이전 IETF 이후, 주로 편집 변경이 세 가지 개정판에서 이루어졌습니다.
    • 큰 변경 사항으로 클라이언트에서 상태 목록 토큰을 요청할 때 요청 헤더 Accept가 'must'에서 'should'로 완화되었습니다.
    • 정의된 Key Usage 의 OID 필드를, 이 드래프트에 의해 작성되는 IANA 레지스트리내의 다른 메카니즘으로 사용할 수 있게 되었습니다.
  • 현재 상태: 모든 미해결 문제와 끌어 오기 요청이 내장되었습니다.

2. 백엔드 Attested Client 인증(Backend Attested Client Authentication)

  • 목적: 기존의 기밀 클라이언트에 의한 인증에는 한계가 있었기 때문에, 프런트 엔드 인스턴스가 아테 스테이션(증명)을 취득해, 그것을 인증 서버에의 클라이언트 인증으로서 직접 사용할 수 있는 메카니즘을 확립합니다.
  • 흐름 개요: 클라이언트 인스턴스가 증명 키를 생성하고 백엔드와의 프로토콜(초안 범위 밖)을 실행하여 JWT 형식의 증명을 가져옵니다.
  • IETF 122 이상 변경:
    • 클라이언트 ID 처리, 클라이언트 증명 사용 및 일반 언어의 명확성.
    • OAuth 오류 응답 값 추가.
    • 가장 중요한 변경 사항으로 챌린지 획득을 위한 HTTP OPTIONS 메커니즘을 폐지하고 HTTP POST 동사를 사용하는 전용 챌린지 엔드포인트로 마이그레이션했습니다.
    • 보안 및 구현 고려 사항 업데이트(재생 보호, JTI 사용 등).
  • DPoP와의 최적화에 대한 토론:
    • 이 클라이언트 인증 메커니즘을 DPoP(Demonstration of Proof-of-Possession)와 함께 사용하는 경우 인증 서버는 3개의 JWT(클라이언트 어테스테이션, 클라이언트 어테스테이션 PoP, DPoP 인증)를 확인해야 합니다.
    • Client Attestation PoP와 DPoP 인증 키가 같으면 Client Attestatiion PoP 대신 DPoP 인증서를 사용하는 최적화 가능성이 논의되었습니다. 이는 요청 헤더를 줄이고 효율성을 향상시킵니다.
    • 보안 문제는 동일한 엔티티에 서명된 메시지를 보내기 위해 동일한 키를 재사용하는 데 문제가 없다는 의견을 표명했습니다.
    • 이 최적화는 필수는 아니며 클라이언트는 DPoP의 유무에 관계없이 작동하도록 준비해야 합니다.
  • 미해결 주요 문제:
    • 챌린지 엔드포인트는 해결된 것으로 간주되며 DPoP 최적화 채택에 대한 의견이 필요합니다.

3. 트랜잭션 토큰 (Transaction Tokens)

  • 목적: 액세스 토큰을 유지하고 컨텍스트 (주체, 컨텍스트, 승인 세부 사항)를 유지하면서 주어진 신뢰 경계 내에서 토큰 교환을 가능하게하는 메커니즘입니다.
  • IETF 122 이상 변경:
    • 범위의 일관성: 트랜잭션 토큰이 원래 액세스 토큰보다 넓은 범위를 갖지 않도록 문장이 엄밀화되었습니다.
    • 인증과 인가의 구별: 트랜잭션 토큰이 인증 구조가 아니라 권한 구조임이 명확해졌습니다.
  • HTTP 헤더 형식과 관련된 과제:
    • IANA 검토자의 피드백은 기존 HTTP 구조화된 헤더 유형이 이 목적에 적합하지 않다고 결론지었다.
    • 결과적으로 구조화되지 않은 헤더로 유지되지만 향후 문제의 위험이 없어졌습니다.
    • 논의는 향후 HTTP 워킹 그룹에 새로운 구조화된 헤더를 요청할 가능성을 제시했지만, 이는 이 규격의 진행을 방해하지 않는다고 여겨졌다.
  • 현재 상태: 개발자는 주요 미해결 문제가 없다고 인식하고 있으며 HTTP 헤더 형식 문제도 해결되었습니다.WGLC로 이동할 준비가 되었습니다..

4. Spiffe 클라이언트 인증(Spiffe Client Authentication)

  • 배경: Spiffe (Secure Production Identity Framework For Everyone)는 클라우드 네이티브 환경에서 워크로드의 정체성을 확립하고 검증하기위한 프레임 워크입니다. (권말에 메모를 둡니다))를 사용하고 있습니다만, 인증 서버와의 인증에는 수동으로 프로비저닝되어, 장기간 유효한 클라이언트 ID와 클라이언트 시크릿이 필요합니다.
  • 제안의 목적: Spiffe가 자동으로 프로비저닝하고 회전하는 단명 인증서와 키 인증 기능이 있는 SVID를 인증 서버에 대한 인증 수단으로 사용할 수 있습니다. 이를 통해 기존 인프라를 활용하고 보호해야 할 비밀을 줄일 수 있습니다.
  • 제안 내용:
    • JWT SVID는 RFC 7523의 클라이언트 인증 부분을, X.509 SVID는 RFC 8705의 MTLS 클라이언트 인증을 프로파일링합니다.
    • 인증 서버는 Spiffe 사양인 Spiffe 번들 엔드포인트(JWKS와 유사)에서 키를 검색하여 SVID를 확인합니다.
  • 주요 논점:
    • iss 클레임 요구 사항: Spiffe의 JWT SVID는 기본적으로iss청구를 포함하지 않기 때문에 RFC 7523iss클레임 요구 사항을 완화하거나 Spiffe 사용자에게iss클레임을 활성화해야 하는지 논의했습니다. 이로 인해 OpenID Connect Discovery 기반 키 배포 메커니즘을 권장 할 수 있습니다.
    • 잠재고객 취급: Spiffe에서 특정 잠재고객이 있는 JWT를 얻을 수 있음을 확인했으며 RFC 7523 및 RFC 25 BIS를 기반으로 인증 서버가 잠재고객이 될 것으로 예상됩니다.
    • 단일 초안 대 분할 초안: JWT SVID와 X.509 SVID를 모두 단일 초안으로 처리할지 아니면 각각의 특성에 따라 별도의 초안으로 나누어야 하는지에 대한 논쟁의 여지가 있다는 의견이 나왔다.
    • 현재 상태: 새 문서이며 리뷰와 피드백이 필요합니다.

5. 새로고침 토큰과 동의 만료(Refresh Token Expiration and Consent Expiration)

  • 목적: 새로 고침 토큰 만료와 사용자 동의 만료라는 두 가지 다른 관련 개념에 대한 메커니즘을 도입하여 사용자에게 사전 통지와 클라이언트가 토큰을 적극적으로 로테이션 할 수 있습니다.
  • 유스케:
    • 동의 유효기간: Google 고객의 요청은 동의가 만료되기 전에 사용자에게 사전 통보하고 서비스 중단을 방지하기 위한 것입니다.
    • 새로 고침 토큰 순환: 클라이언트가 자주 토큰을 사용하지 않는 경우(예: 사용자가 사이트에 액세스할 때만) 적극적인 순환이 필요한지 여부를 알아야 합니다.
  • 제안 내용: 토큰 끝점의 응답에 두 개의 새 매개 변수 refresh_token_expires_in과 consent_expires_in을 추가합니다.
  • 주요 논점:
    • 시간 한정 토큰 요청 매개변수: 클라이언트가 시간 제한 토큰을 요청하기위한 매개 변수 (예 : 권한 흐름 요청 또는 토큰 끝점 요청)를 정의해야합니까?
    • expires_in vs expires_at: 현재 RFC 6749는 액세스 토큰에 expires_in(상대 시간)을 사용하고 있지만 expires_at(절대 시간)의 편의성(클라이언트가 시스템 시간을 체크할 필요가 없는 로컬 캐시의 가능성)이 논의되었습니다. 만약 expires_at가 채용되는 경우,
    • 동의에 관한 용어: "동의"라는 용어는 OAuth의 기본 사양에 명시 적으로 정의되지 않았기 때문에이 개념을 매개 변수 이름에 도입하는 것이 적절하다는 논의가있었습니다.
    • 구현 노트: 인증 서버가 동의 만료일을 처리하는 방법에 대한 비규범적인 구현 노트를 추가해야 하는가?
  • 현재 상태: 초안은 존재하며 피드백과 검토가 요구되고 있습니다. 특히 동의에 관한 용어나 expires_at의 사용 및 그랜트 관리 API와의 관련성에 대해 우려가 있습니다.

6. 브라우저 없는 앱 간 페더레이션 (Browserless App-to-App Federation)

  • 배경: OAuth의 RC8252 (앱 대 웹) 및 Joseph Heenan (Authlete CTO) 의 "앱 대 앱" 블로그에서 제안된 모델은 클라이언트 앱과 권한 서버 앱이 동일한 신뢰 도메인에 속하는 경우에 효과적입니다.그러나 여러 신뢰 도메인에 걸친 페더레이션 시나리오(예: 학술기관이나 다국적 기업)에서는 중간 리디렉션을 위해 브라우저가 필요해져 사용자 경험의 저하나 잠재적인 문제
  • 문제점:
    • 브라우저를 통한 리디렉션은 사용자 경험을 악화시킨다(지연, 중단, 탭 산란).
    • 다른 브라우저(Web View 등)가 사용되면 쿠키 불일치 등으로 플로우가 중단될 가능성이 있다.
  • 제안의 목적: 브라우저를 통하지 않고 앱이 자신의 사용자 에이전트가 되어 직접 리디렉션을 처리하여 여러 트러스트 도메인에 걸친 페더레이션을 실현합니다.
  • 제안 내용:
    • 클라이언트 앱이 자체 사용자 에이전트가 되어 HTTP 클라이언트로 리디렉션을 추적합니다.
    • 각 URL을 검색하여 기기에 해당 URL에 해당하는 앱이 있는지 확인합니다.
    • 사용자 인증 앱이 사용자를 인증하고 작업을 승인한 후 딥 링크 URL을 두 앱간에 공유하며, 사용자 인증 앱은 모범 사례와는 반대로 이 기본 콜백 URL을 신뢰하고 리디렉션 URL과 함께 콜백을 반환합니다.
    • 신뢰의 확립에는 OpenID Federation이나 자동 클라이언트 등록(←OpenID Federation의 Automatic Registration과는 별개이므로 이름을 바꿔야 한다는 지적이 들어 있음) 또는 닫힌 에코시스템에서의 사전등록된 신뢰를 이용할 수 있습니다.
  • 주요 논점:
    • 인증 서버 측 동작: 인증 서버가 사용자와 상호 작용하지 않고 연속 30x 리디렉션을 반환하는 시나리오의 실현 가능성.
    • 보안 고려 사항: 브라우저를 사용하지 않아 사용자의 보안 의식(어느 오리진에서 인증하는지)의 저하의 우려.
    • 폴백 옵션: 브라우저리스로 실현이 불가능한 경우에 대비하여 브라우저에 대한 폴백 옵션을 항상 제공합니다.
  • 현재 상태: OSW에서 발표되었으며 활성 유스 케이스가 존재합니다.

7. 클라이언트 확장 클레임 (Client Extension Claims)

  • 배경: OAuth에서 보안 메커니즘 (MTLS, DEOP, Private Key JWT 등) 사용에 대한 정보를 액세스 토큰 페이로드에 포함시킴으로써 리소스 서버가 이러한 정보를 정책 결정에 사용할 수 있도록합니다. Credentials 등), 클라이언트 인증 방법 등 다양한 장소에 산재하고 복잡한 처리가 필요합니다.
  • 문제점:
    • 토큰의 종류(ID 토큰인가 액세스 토큰인가)의 판별이 복잡.
    • 사용된 권한 부여 그랜트 흐름에 대한 정보가 부족합니다.
    • 키 바인딩(PKCE, RAR, JAR)에 대한 정보가 부족합니다.
    • 클라이언트 인증 방법(Private Key JWT, MTLS)에 대한 정보가 부족합니다.
    • 이러한 정보가 HTTP 헤더에 분산되어 있고 백엔드의 정책 결정 지점이 페이로드에만 액세스할 수 있는 경우 문제가 발생합니다.
  • 제안 내용: 액세스 토큰 페이로드에 네 가지 새로운 클레임을 도입합니다.
    • gty (Grant Type): 사용 된 그랜트 플로우의 유형을 설명하는 단일 문자열.
    • cxt (Client Extension Type): Pixie, DPoP, JAR 등, 사용된 클라이언트 인증 확장 방법의 조합을 기술하는 캐릭터 라인의 배열.
    • ccr (Client Credential Reference): 사용자의 ACR 클레임에 해당하며 AS와 ARS 간에 신뢰를 전달하는 네임스페이스를 제공합니다.
    • cmr (Client Method Reference): 클라이언트 인증 방법(MTLS 등)을 기술해, IANA 레지스트리로 값을 등록할 예정입니다.
  • 장점:
    • 새 요청 매개변수를 도입하지 않으므로 인증 서버는 기존 API를 변경하지 않고 이러한 클레임을 리턴할 수 있습니다.
    • 인증 서버 메타데이터에 runtime_type_extension을 도입하여 이러한 기능에 대한 지원을 선언할 수 있습니다.
  • 주요 논점:
    • Vectors of Trust와의 유사성: Trust Decision의 다양한 요소를 나타내는 기존 메커니즘인 Vectors of Trust(RFC 8584)와의 관련성.
    • gty 값의 표준화: Okta나 Auth0 등, 이미 gty와 같은 클레임을 사용하고 있는 벤더가 존재하지만, 그 값이 다를 가능성이 있기 때문에, 표준화의 필요성.
  • 리뷰어 모집: 문서 검토 및 피드백이 필요합니다.

8. 권한 부여 계층에서 스텝업 인증(Step-up Authentication at the Authorization Layer)

  • 배경: RFC 9470 (스텝 업 인증)은 리소스 공급자가 클라이언트에게 더 강력한 인증을 요구하기 위해 WWW-Authenticate 헤더를 통해 추가 정보 (예 : 다른 ACR)를 반환하는 메커니즘을 제공했습니다.
  • 문제점:
    • 리소스 제공자가 클라이언트에게 왜 진행할 수 없는지에 대한 자세한 정보(예: 특정 요구사항 및 조건)를 전달하는 수단이 부족하다.
    • FAPI 2.0 및 Smart on FHIR과 같은 프레임워크는 클라이언트 인증 요구사항과 Rich Authorization Request(RAR)를 지원하지만 리소스 서버가 클라이언트를 다음 단계로 안내하기 위한 보다 자세한 신호를 보내는 기능이 필요합니다.
    • Shared Signal Framework(SSF)의 등장에 의해, 리소스 프로바이더의 결정이 동적으로 변화할 가능성이 있기 때문에, 클라이언트에 최신의 정보를 전할 필요가 생긴다.
  • 제안 내용:
    • 허가 레이어에서 신호를 전달할 수 있도록 특정오류 코드와도전소개합니다.
  • 특정 도전:
    • 리소스 서버가 클라이언트에게 자신의 OAuth 2.0 Protected Resource Metadata를 참조하도록 지시하는 기능.
    • 클라이언트에게 다음에 해야 할 일을 RAR(Rich Authorization Request) 형식으로 안내하는 기능.
  • 응답 봉투: 권한 부여와 관련하여 RAR의 authorization_details 형식을 응답의 봉투로 사용합니다. 이렇게 하면 기존 RAR 사양을 준수하는 형식으로 지불에 대한 특정 요구사항과 같은 정보를 고객에게 알릴 수 있습니다.
  • 장점:
    • 클라이언트가 리소스 서버로부터 자세한 지침을 받고 적절한 권한 요청을 빌드하고 새로운 액세스 토큰을 얻을 수 있습니다.
    • FAPI 2.0, Smart on FHIR, MCP 등 기존 사양과의 연계를 강화합니다.
  • 주요 논점:
    • HTTP 상태 코드 401 vs 403: RFC 9470이 401을 사용하는 반면, 본 제안은 허가와 관련된 문제로 403의 사용을 제안하고 있습니다.
    • 페이로드 및 헤더: 정보를 페이로드에 포함할지, 헤더에 포함할지 (예 : JWT를 헤더에 포함) 등에 대한 논의가있었습니다.
    • GNAP과의 무결성: GNAP(General Authorization and Negotiation Protocol)와의 무결성도 고려 사항입니다.
  • 현재 상태: OSW에서 발표 된 이전의 복잡한 솔루션에서 간소화되었습니다. 피드백과 리뷰를 요청했습니다.

9. 푸시형 클라이언트 등록(Pushed Client Registration)

  • 배경: OAuth는 클라이언트 ID를 중심으로 구축되어 있지만 SPA나 네이티브 앱 인스턴스와 같은 임시(임시) 클라이언트에는 기존의 영구적인 클라이언트 ID 개념이 반드시 적용되지는 않습니다.
  • 문제점:
    • 임시 클라이언트에 대한 클라이언트 ID의 적절한 관리 및 수명 주기.
    • 동적 등록 후 여분의 클라이언트 ID 정리 필요.
    • 클라이언트 메타데이터 호스팅의 필요성.
  • 제안 내용: PAR (Pushed Authorization Requests)을 기반으로 클라이언트 ID를 명시 적으로 사용하지 않고 동적으로 자신을 인증하는 방법을 제안합니다.
    • PAR 요청: 클라이언트는 PAR 요청을 수행하고 client_id 매개 변수에 "dynamic"과 같은 특수 키워드를 사용합니다.이 경우 클라이언트 메타 데이터 문서도 푸시됩니다.
    • PAR 응답: 인증 서버는 클라이언트 ID를 반환하지 않고 일반 request_uri 만 반환합니다.
    • 권한 엔드포인트: 클라이언트는 request_uri를 사용하여 권한 부여 엔드 포인트에 액세스하고 여기에서도 client_id로 "dynamic"키워드를 사용합니다.
    • 토큰 엔드포인트: 인증 코드를 받은 후 클라이언트는 토큰 엔드포인트에 요청하고 다시 client_id로 "dynamic" 키워드를 사용하여 원래 푸시된 권한 요청에 도입된 키의 증명을 제공합니다.
  • 장점:
    • 동적 등록의 여분의 왕복을 줄이고 남은 클라이언트 ID를 삭제할 필요가 없습니다.
    • 클라이언트 메타데이터를 호스팅할 필요 없이 인스턴스별 정보를 푸시할 수 있습니다.
    • 클라이언트 증명 및 소프트웨어 문과 같은 클라이언트의 신뢰 인프라에 결합할 수 있는 정보를 푸시할 수 있습니다.
  • 주요 논점:
    • 문제 해결 필요: 이 문제가 커뮤니티 전체로 해결해야 할 것인가?
    • 여러 접근법의 공존: 클라이언트 ID 문제에 대한 여러 가지 다른 솔루션이 제안 된 현재 상황에 대한 공존 가능성과 통일적 접근의 필요성.
    • 적용 범위 가드 레일:이 접근법이 의미있는 유스 케이스에 엄격한 가드 레일을 설정할 필요성.
  • 현재 상태: 프로토타입 구현이 작동하고 있으며 보안상의 큰 우려는 발견되지 않았습니다.

10. 지연 키 바인딩 (Deferred Keybinding)

  • 배경: 기존 OAuth의 PoP 메커니즘 (DPoP 및 MTLS)은 토큰이 발행되기 전에 키의 증명 (소유 증명)을 제시하도록 요구합니다.
  • 문제점:
    • 다른 도메인의 키를 바인딩해야하는 경우 대상 리소스는 발표자를 확인할 수 있지만 요청 소스 엔터티는 동일한 방식으로 요청을 수행 할 수 없습니다.
    • IoT 장치의 하드웨어 게시 키와 같이 장치에 키가 유지되고 해당 키에 토큰이 바인딩되지만 발급 시 키의 소유 증명을 제시할 수 없는 시나리오입니다.
    • Spiffe 에이전트가 워크로드 대신 토큰을 발행하고 워크로드에 전달할 때 Spiffe 에이전트가 워크로드의 개인 키를 소유하지 않는 시나리오.
  • 제안 내용과 방향성 선택: 워킹그룹에게 이 문제에 어떻게 대처해야 할지에 대한 논의가 요구되고 있습니다.
    • 옵션 0: 무시: 이 행위를 「나쁜 습관」이라고 선언하고, 비추천으로 한다. 그러나 현실에는 이미 이 방법으로 해결하고 있는 경우가 있기 때문에 이를 멈출 수 없다.
    • 옵션 1: 기존 패턴 문서화: 기존의 패턴과 유스 케이스를 문서화해, 매우 나쁜 관행에는 가드 레일을 설정해, 의미가 있는 경우에만 적용되도록 한다.
    • 옵션 2: 프로토콜 사양 구축: 유지되지 않은 확인 키를 토큰 요청의 일부로 제시하는 방법을 형식화하는 프로토콜 확장을 구축한다. 이것은 MTLS, DEOP, HTTP SIG 등의 기존의 서명 베이스의 메카니즘에 통합될 가능성이 있다.
    • 옵션 3: 토큰 데이터 사양 추가: JWT나 인트로스펙션 등의 토큰 데이터 사양에, 「토큰이 바인드 된 키이지만, 발행시에는 제시되지 않았다」를 나타내는 방법을 추가한다.
  • 인용: “The basic idea boils down to allowing the client to say “Hey I have my identity that I can prove but the token that you give me I want it bound to somebody else's keys.” And so I want you to give me back the token that is bound to somebody else's keys And trust me I am allowed to do this” (기본적인 사고방식은 클라이언트가 "나는 자신의 신원을 증명할 수 있지만, 당신이 나에게주는 토큰은 다른 누군가의 키에 바인딩해 주었으면 한다"고 말하게 하는 것에 귀착합니다.
  • 주요 논점:
    • 문제의 긴급성: 이 문제는 다른 곳에서도 볼 수 있으며, 다루지 않으면 아무도 도울 수 없다는 의견.
    • 보안 위험과 오용 가능성: 이 메커니즘이 악용될 수 있으며 위험하다는 우려.
    • 정책 및 동적 행동과의 관계: 이 문제가 정책이나 동적인 행동 없이 완전하게 해결할 수 있을지는 불명.
    • SAML의 subject_confirmation_data와의 유사성: SAML의 subject_confirmation_data(cnf) 클레임과의 개념적 유사성.
    • 커뮤니티 공수: 옵션 2 또는 3 구축에는 상당한 노력이 걸린다는 우려.
    • Brian의 의견: 옵션 0(아무것도 하지 않는다)를 선호한다고 표명. 이유는 「게으름」과 「작업에 소모되는 것에 대한 우려」.
  • 현재 상태: 초안은 문제 제기를 목적으로 하며 채용 여부는 묻지 않습니다. 메일링 리스트에서의 논의를 통해 워킹그룹으로서 어느 방향성으로 나아갈 것인가에 대한 합의를 형성하는 것이 제안되었다.

OAuth WG Session 녹화

(마지막으로 한순간 나도 나옵니다w)

YouTube에서 이 동영상 보기.
동영상을 재생하면 YouTube에 연결됩니다.

(SVID에 대한 메모)

SVID(SPIFFE Verifiable Identity Document)는 SPIFFE에 의해 정의워크로드(애플리케이션 및 서비스 등)가 자신의 '신원(Identity)'을 증명하는 디지털 인증서SVID는 현실 세계에서 '여권'과 같은 역할을 합니다.

주요 특징:

  • SPIFFE ID 포함: 워크로드 고유의 고유 식별자(spiffe://로 시작하는 URI)를 포함합니다.
  • 디지털 서명 포함: 트러스트 도메인의 CA(Certificate Authority)가 서명했기 때문에 제3자가 그 정확성을 확인할 수 있습니다.
  • 형태: X.509 인증서 형식(X.509 SVID) 또는 JWT 형식(JWT SVID)으로 표준화되어 있습니다.
  • 단기간 유효 & 자동 갱신: 보안을 위해 수명이 짧고 자동으로 회전됩니다.
  • 用途: 서비스간의 mTLS(상호TLS) 통신이나 API 인증 등, IP 주소 등의 네트워크 정보에 의존하지 않고, 안전하게 워크로드끼리의 통신의 인증·인가를 실현할 수 있습니다1345.

이미지로서 'SVID'는 다음과 같은 정보를 보유합니다 :

  • 단일 SPIFFE ID
  • 필요에 따라 공개키
  • 디지털 서명

서비스(워크로드)는 SPIFFE Workload API를 통해 자신만의 SVID를 취득하여 통신 상대에게 제시함으로써제로 트러스트 환경실현의 중심적인 역할을 담당합니다.