# OAuth 2.0 Token Exchange의 다양한 얼굴 > Clean Markdown view of GeekNews topic #30164. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30164](https://news.hada.io/topic?id=30164) - GeekNews Markdown: [https://news.hada.io/topic/30164.md](https://news.hada.io/topic/30164.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-04T10:22:02+09:00 - Updated: 2026-06-04T10:22:02+09:00 - Original source: [auth0.com](https://auth0.com/blog/the-many-faces-of-oauth2-token-exchange/) - Points: 1 - Comments: 0 ## Topic Body - 하나의 보안 토큰을 다른 토큰으로 변환하는 **표준 기반 메커니즘**으로, RFC 8693에 정의된 OAuth 2.0 확장 사양 - 인가 서버를 **Security Token Service(STS)** 로 전환해, 클라이언트가 보낸 토큰을 검증하고 다른 컨텍스트·대상(audience)·목적에 맞는 새 토큰을 발급 - 동작 방식은 크게 **임퍼소네이션(Impersonation)** 과 **위임(Delegation)** 두 모드로 구분 - 관리자 임퍼소네이션, 프로토콜 전환, 서비스 체이닝, 페더레이션 ID 등 **각기 다른 사용 사례**마다 트레이드오프와 보안 영향이 존재 - **AI 에이전트**의 확산으로 여러 서비스·제공자를 오가는 작업이 본질적으로 위임 체인이 되면서, 토큰 교환의 중요성이 더 커짐 --- ### 토큰 교환(Token Exchange)이란 - 클라이언트가 `subject_token`(요청 주체인 사용자/엔터티를 나타내는 토큰)을 보내고, 선택적으로 `actor_token`(교환을 수행하는 당사자)을 함께 보내면 대상 컨텍스트에 맞는 새 토큰을 수신 - 기존 토큰을 그대로 전달하거나 새 토큰을 새로 만드는 방식은 직관적으로 보이지만, 둘 다 심각한 문제를 유발하므로 이를 해결하기 위해 만들어진 사양 - ## 두 가지 기본 동작 모드 - **Impersonation**: 요청 당사자가 원래 주체와 구별 불가능한 토큰을 수신, 다운스트림 서비스는 실제 사용자인지 가장한 당사자인지 구분 불가 - **Delegation**: 두 주체의 정체성을 모두 보존, 새 토큰에 포함된 `act`(actor) 클레임을 통해 다운스트림 서비스가 사용자와 대리 수행자를 모두 인지 - 임퍼소네이션은 강력하지만 불투명, 위임은 제약이 있지만 감사(audit) 가능 — 이 선택이 보안 태세와 추적 능력을 결정 ### 관리자 임퍼소네이션 (Administrative Impersonation) - 고객 대시보드에 잘못된 데이터가 표시되는 문제를 진단하기 위해, 지원 엔지니어가 고객과 동일한 권한·데이터 접근으로 화면을 그대로 확인해야 하는 상황 - 관리자가 자신의 토큰을 고객 정체성을 나타내는 토큰으로 교환, 결과 토큰은 고객의 `sub` 클레임·스코프·audience를 포함하므로 애플리케이션 관점에서는 고객이 보낸 요청으로 인식 - 이 경우 요청은 `subject_token`(가장할 사용자)만 사용하고 `actor_token`은 제공하지 않음 — 완전한 임퍼소네이션이 목적이기 때문 - ## 감사 추적 손실 문제 - 진짜 임퍼소네이션이므로 실제로 누가 행동을 수행했는지에 대한 감사 추적이 사라짐 - 따라서 **누가, 언제, 어떤 이유로** 교환을 시작했는지 기록하는 외부 로깅 메커니즘과 반드시 병행해야 함, 그렇지 않으면 문제 해결을 빌미로 보안 공백 발생 ### 프로토콜 전환 관리 (Managing Protocol Transition) - 레거시 시스템과 구형 프로토콜이 남아 있는 환경에서, **SAML 인증에서 OpenID Connect(OIDC)** 로 마이그레이션하면서 두 시스템을 동시 운영하는 시나리오 - SAML로 사용자를 인증하는 서비스가 **SAML assertion을 OAuth 2.0 액세스 토큰**으로 교환, 인가 서버가 들어온 SAML 아티팩트를 검증하고 다운스트림이 이해하는 표준 액세스 토큰을 발급 - ## subject_token_type 파라미터 - 들어오는 토큰의 형식을 식별, RFC 8693은 여러 토큰 타입 식별자를 정의 - SAML 2.0 assertion: `urn:ietf:params:oauth:token-type:saml2` - JWT 토큰: `urn:ietf:params:oauth:token-type:jwt` - 인가 서버가 서로 다른 프로토콜 계열의 토큰을 받아들여 현대 서비스용 일관된 형식으로 정규화 가능 - 기업 인수·합병으로 서로 다른 ID 스택을 가진 두 조직이 완전 마이그레이션 전에 상호 운용해야 할 때 등장하는 패턴, 사용자는 기존 방식대로 인증하고 시스템이 자격 증명을 소비 서비스가 요구하는 형태로 변환 ### 서비스 호출 체이닝 (Chaining Service Calls) - 마이크로서비스 아키텍처에서 Service A가 사용자 요청을 처리한 뒤 사용자를 대신해 Service B를, 다시 Service B가 Service C를 호출해야 하는 상황에서 **각 서비스가 다음 호출에 어떤 자격 증명을 쓸지**가 핵심 질문 - ## 옵션 1 — 서비스 자체 자격 증명 사용 - Service A가 사용자 컨텍스트를 무시하고 자신의 클라이언트 자격 증명으로 Service B 호출, 배치 처리·시스템 상태 점검·데이터 동기화 등 사용자 컨텍스트가 불필요한 서비스 간 호출에 적합 - 사용자가 관련될 때는 Service B가 사용자 수준 인가를 강제할 수 없음 — 어떤 사용자가 요청했는지 알 수 없어 접근 권한 확인 불가, 보안 컨텍스트 상실 - ## 옵션 2 — 서비스가 사용자를 임퍼소네이션 - Service A가 사용자 원본 토큰을 그대로 Service B에 전달하거나 사용자와 구별 불가능한 토큰으로 교환, Service B는 사용자 발신 요청으로 보고 사용자 수준 인가 적용 - Service B가 사용자의 직접 행동과 Service A의 대리 행동을 구분 불가, Service A가 침해되면 사용자 권한 내 모든 호출 가능하며 직접/프록시 요청에 다른 신뢰 수준 적용 불가 — 사용자 컨텍스트는 보존하나 서비스 컨텍스트 상실 - ## 옵션 3 — 사용자를 대신해 행동 (Delegation) - Service A가 사용자 토큰을 **사용자(subject)와 Service A(actor)** 를 모두 식별하는 새 토큰으로 교환, 결과 토큰의 `act` 클레임이 "User X에 관한 요청, Service A가 수행"을 전달 - RFC 8693이 주로 지원하도록 설계된 위임 모델, Service B가 정교한 인가 판단 수행 가능 — Service A가 사용자가 허가하지 않은 작업을 시도하면 요청 실패 - `act` 클레임은 중첩(nestable) 가능, Service B가 Service C를 호출하면 위임 체인이 확장되어 완전한 감사 추적 제공 - 트레이드오프는 복잡성 — 각 홉마다 토큰 교환이 필요해 지연 시간이 늘고 각 서비스가 인가 서버에 클라이언트로 등록되어야 함, 그러나 보안·감사가 중요한 아키텍처에서는 원칙적 선택 ### 토큰 교환과 페더레이션 ID - 서비스가 보안 도메인을 넘나들 때(예: 제3자 조직이 제공하는 서비스) 체인 시나리오가 훨씬 복잡해짐 - Service A는 MyCompany 보안 도메인 내 사용자를 대신해 Service B에 접근하는 토큰 보유 - Service B는 External Provider 도메인에서 보호되는 Service C를 호출해야 하며, 이를 위한 액세스 토큰 필요 - MyCompany 인가 서버가 발급한 토큰은 External Provider 도메인에서 무의미 — 한 인가 서버가 발급한 토큰을 다른 서버가 자동 수용하지 않음, 신뢰 경계는 피해 범위(blast radius)를 제한하기 위해 존재 - ## 페더레이션 구성의 한계 - External Provider 인가 서버가 MyCompany 도메인의 토큰을 유효한 subject 토큰으로 받아들이도록 구성되어야 함, 메타데이터 교환·인증서 검증·직접 구성을 통한 사전 신뢰와 도메인 간 정체성 매핑 필요 - 도메인이 늘어날수록(엔터프라이즈 통합, SaaS 생태계, 멀티 클라우드) 양자 간 신뢰 관계의 매트릭스가 관리 불가능해짐 - ## Cross App Access와 Identity Chaining - 이 확장 문제를 해결하기 위한 **Cross App Access(XAA)**, Identity Assertion JWT Authorization Grant를 구현하며 교차 도메인 교환에 **엔터프라이즈 IdP**를 중재자로 도입 - IdP가 이미 두 애플리케이션과 사용자 관계를 알고 있다는 통찰을 활용, 모든 도메인 쌍이 양자 신뢰를 맺는 대신 접근 결정을 IdP에 집중 - ### XAA 흐름의 4개 당사자 - **Requesting App**: 다른 도메인 리소스에 접근해야 하는 MyCompany 도메인의 애플리케이션(또는 AI 에이전트) - **Enterprise IdP**: 직원을 인증하고 교차 앱 정책을 관리하는 MyCompany 도메인 ID 제공자 - **Resource App**: External Provider 도메인에서 보호된 API를 소유한 애플리케이션 - **Resource Authorization Server**: Resource App의 보호 API용 액세스 토큰을 발급하는 인가 서버 - ### XAA 단계별 흐름 - 직원이 SSO로 Requesting App에 로그인해 IdP로부터 ID 토큰 획득 - Requesting App이 해당 ID 토큰을 IdP에 다시 보내 교차 도메인 정체성 어서션(**ID-JAG**, 교차 앱용으로 스코프된 특수 JWT) 요청 - IdP가 XAA 정책 확인 — 이 사용자를 대신해 Resource App 접근이 허용되는지 판단, 허용 시 ID-JAG 반환 - Requesting App이 ID-JAG를 Resource App 인가 서버에 제시 - Resource App 인가 서버가 OIDC discovery로 IdP 공개 키를 사용해 ID-JAG 검증 후 액세스 토큰 발급 - Requesting App이 해당 액세스 토큰으로 Resource App API 호출 - 일반 토큰 교환과의 결정적 차이는 3단계에서 IdP가 정책 결정을 강제 — 관리자가 어떤 앱이 어떤 리소스에 도달할 수 있는지 명시적으로 구성, IT에 가시성과 통제 제공하며 사용자는 반복 동의 흐름 회피 - **Identity Chaining**은 사용자 정체성 어서션이 최초 인증부터 모든 다운스트림 서비스까지 표준화된 방식으로 흐르는 더 넓은 패턴, XAA는 OAuth 프리미티브 기반의 한 구현 - 단일 사용자 요청이 여러 제3자 제공자의 서비스 호출을 유발하는 **AI 에이전트** 시나리오에서 특히 관련 ### 토큰 교환과 Auth0 - Auth0는 앞서 다룬 스펙트럼의 서로 다른 지점을 다루는 메커니즘으로 토큰 교환을 구현 - ## Custom Token Exchange - Auth0의 `/oauth/token` 엔드포인트에서 RFC 8693을 구현, 검증 로직에 대한 완전한 개발자 통제 제공 - `subject_token_type` URI를 커스텀 Action에 매핑하는 **Token Exchange Profile** 정의, 요청 도착 시 Auth0가 Action 코드를 호출해 토큰 검증·인가 규칙 강제·테넌트 내 사용자 연결 - Auth0가 `subject_token`을 불투명 문자열로 취급하므로 다른 IdP의 JWT, 레거시 SAML assertion, 파트너 API의 독자 토큰 등 어떤 형식도 수용 — 프로토콜 전환·커스텀 페더레이션용 메커니즘 - ## Token Vault - 여러 제공자에 걸쳐 사용자를 대신해 제3자 API를 호출하는 **AI 에이전트** 시나리오용, 토큰 교환에 안전한 저장과 자동 수명 주기 관리를 추가 - 사용자가 인증 후 계정(Google, GitHub, Slack, Microsoft 등) 연결, Token Vault가 토큰을 안전하게 저장하고 갱신을 자동 처리, AI 에이전트가 토큰 교환으로 유효한 액세스 토큰을 보관소에서 회수 - 결과 토큰에 AI 에이전트를 식별하는 `act` 클레임 포함 — 어떤 에이전트가 어떤 사용자를 대신해 어떤 서비스에 접근했는지 감사 추적 생성, 무엇이 자동화를 촉발했는지 알아야 하는 엔터프라이즈 컴플라이언스에 필수 - ## On-Behalf-Of (OBO) Token Exchange - 서비스 체인 시나리오용으로 위임 패턴을 직접 구현, 중간 계층 서비스가 들어온 사용자 토큰을 다운스트림 API에 스코프된 새 토큰으로 교환하며 `act` 클레임으로 위임 체인에 자신을 추가 - 최대 **5단계 위임 체인 중첩** 지원, 각 토큰은 `sub`(사용자 정체성 유지)·`aud`(대상 서비스 스코프)·중첩 `act`(관여 서비스 체인 기록) 클레임을 보유 - ## Cross App Access (XAA) - 요청 애플리케이션이 다른 인가 서버가 보호하는 리소스 API를 호출해야 하는 페더레이션 ID 시나리오용, Identity Assertion Authorization Grant OAuth 확장 구현 - Auth0가 Resource Authorization Server 역할 수행 — Requesting App이 사용자 ID 토큰을 Okta 등 IdP에 보내 ID-JAG 수신, 관리자가 Admin Console에서 교차 앱 연결을 구성한 경우에만 IdP가 어서션 발급 - Requesting App이 ID-JAG를 Auth0에 제시하면 OIDC discovery로 검증 후 스코프된 액세스 토큰 발급, IT에 교차 앱 데이터 공유에 대한 중앙 집중식 가시성 제공 ### 올바른 접근 선택하기 - 토큰 교환은 단일 솔루션이 아니라 패턴의 집합, 보존할 컨텍스트와 넘어야 할 신뢰 경계에 따라 선택이 달라짐 - **관리자 임퍼소네이션**: 문제 해결 시 사용자가 보는 화면을 그대로 봐야 할 때 - **프로토콜 전환**: 마이그레이션 중 레거시와 현대 ID 시스템을 잇는 다리가 필요할 때 - **위임(Delegation)**: 서비스 체인이 완전한 감사 가능성과 함께 사용자 컨텍스트를 요구할 때 - **Cross App Access / Identity Chaining**: 위임이 여러 보안 도메인에 걸칠 때 - **Token Vault**: AI 에이전트가 사용자를 대신해 제3자 API에 대한 관리된 접근이 필요할 때 - 여러 서비스·제공자에 걸쳐 사용자를 대신해 작업을 오케스트레이션하는 AI 에이전트는 본질적으로 위임 체인, 토큰 교환 메커니즘이 그 체인을 감사 가능하고 인가되며 사용자 의도에 스코프되도록 만드는 보안 기반 제공 ## Comments _No public comments on this page._