OAuth 2.0 Token Exchange의 다양한 얼굴

하나의 보안 토큰을 다른 토큰으로 변환하는
표준 기반 메커니즘으로, 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 에이전트는 본질적으로 위임 체인, 토큰 교환 메커니즘이 그 체인을 감사 가능하고 인가되며 사용자 의도에 스코프되도록 만드는 보안 기반 제공