OAuth 2.0 Token Exchange의 다양한 얼굴 — 임퍼소네이션부터 AI 에이전트 위임 체인까지

OAuth 2.0 Token Exchange의 다양한 얼굴 — 임퍼소네이션부터 AI 에이전트 위임 체인까지

OAuth 2.0 Token Exchange는 RFC 8693으로 표준화되어 있지만, 실제 적용 맥락에 따라 전혀 다른 보안 특성을 가집니다. 같은 메커니즘이라도 관리자 지원 시나리오와 AI 에이전트 위임 체인에서는 트레이드오프가 완전히 달라집니다. 이번 글에서는 Auth0 팀이 정리한 사용 사례별 패턴과 한국 개발 환경에서 마주할 만한 의사결정 포인트를 함께 살펴봅니다.

토큰 교환이란 무엇인가

토큰 교환은 클라이언트가 subject_token(요청 주체인 사용자를 나타내는 토큰)을 보내고, 선택적으로 actor_token(교환을 수행하는 당사자)을 함께 보내면, 인가 서버가 이를 검증해 대상 컨텍스트와 audience에 맞는 새 토큰을 발급하는 메커니즘입니다. RFC 8693은 이 흐름을 Security Token Service(STS) 패턴으로 정의합니다.

기존 토큰을 그대로 전달하거나 매번 새로 만드는 방식은 직관적으로 보이지만, 두 방식 모두 보안상 문제를 만듭니다. 그대로 전달은 audience 검증이 사라지고, 매번 새로 발급은 사용자 컨텍스트가 유실됩니다. 토큰 교환은 이 두 극단 사이에서 검증과 변환을 분리해 해결책을 제공합니다.

두 가지 기본 모드

토큰 교환은 두 가지 핵심 모드로 구분됩니다.

임퍼소네이션(Impersonation): 요청 당사자가 원래 주체와 구별 불가능한 토큰을 수신합니다. 다운스트림 서비스 입장에서는 사용자가 직접 보낸 요청인지, 대리인이 보낸 요청인지 알 수 없습니다. 강력하지만 불투명해서 감사 추적이 어렵습니다.

위임(Delegation): 두 주체의 정체성을 모두 보존합니다. 새 토큰에 포함된 act(actor) 클레임을 통해 다운스트림 서비스가 사용자와 수행자를 모두 인지할 수 있습니다. 제약은 있지만 완전한 감사 체인을 구성할 수 있어 보안이 중요한 환경에서 우선 선택됩니다.

관리자 임퍼소네이션

고객 대시보드에 잘못된 데이터가 표시되는 문제를 진단할 때, 지원 엔지니어는 고객과 동일한 권한으로 화면을 그대로 확인해야 합니다. 이때 관리자가 자신의 토큰을 고객 정체성으로 교환하면, 결과 토큰은 고객의 sub 클레임과 스코프, audience를 그대로 포함합니다.

이 패턴은 강력한 디버깅 도구이지만, 진짜 임퍼소네이션이므로 누가 어떤 작업을 수행했는지 감사 추적이 사라집니다. 따라서 외부 로깅 메커니즘을 반드시 병행해야 합니다. 그렇지 않으면 문제 해결을 빌미로 보안 공백이 생길 수 있습니다.

프로토콜 전환

레거시 시스템과 구형 프로토콜이 공존하는 환경, 특히 SAML에서 OpenID Connect로 마이그레이션하는 단계에서 토큰 교환이 다리 역할을 합니다. SAML로 인증된 사용자의 assertion을 OAuth 2.0 액세스 토큰으로 교환하면, 인가 서버가 서로 다른 프로토콜 계열의 토큰을 받아들여 현대 서비스용 일관된 형식으로 정규화할 수 있습니다.

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 스택을 가진 두 조직이 완전 마이그레이션 전에 상호 운용해야 할 때 이 패턴이 빛을 발합니다.

서비스 호출 체이닝

마이크로서비스 아키텍처에서 Service A가 사용자 요청을 처리한 뒤 Service B를, 다시 Service B가 Service C를 호출해야 하는 상황이 흔합니다. 이때 각 서비스가 다음 호출에 어떤 자격 증명을 쓸지가 핵심 설계 결정입니다.

옵션 1 — 서비스 자체 자격 증명: 사용자 컨텍스트가 불필요한 시스템 간 호출에 적합합니다. 배치 처리, 상태 점검, 데이터 동기화처럼 사용자가 관련되지 않은 작업에서 사용합니다. 다만 사용자 수준 인가를 강제할 수 없으므로 보안 컨텍스트가 사라집니다.

옵션 2 — 임퍼소네이션 체이닝: Service A가 사용자 원본 토큰을 그대로 전달하거나 사용자와 구별 불가능한 토큰으로 교환합니다. Service B는 사용자 발신 요청으로 보고 사용자 수준 인가를 적용합니다. 사용자 컨텍스트는 보존되지만, Service A가 침해되면 사용자 권한 내 모든 호출이 가능해집니다.

옵션 3 — 위임 체이닝: Service A가 사용자 토큰을 subject(사용자)와 actor(Service A)를 모두 식별하는 새 토큰으로 교환합니다. 결과 토큰의 act 클레임이 "User X에 관한 요청, Service A가 수행"을 전달합니다. RFC 8693이 주로 지원하도록 설계한 위임 모델이며, Service B가 정교한 인가 판단을 수행할 수 있습니다.

act 클레임은 중첩 가능해서 Service B가 Service C를 호출하면 위임 체인이 확장되며 완전한 감사 추적이 제공됩니다. 트레이드오프는 복잡성입니다. 각 홉마다 토큰 교환이 필요해 지연 시간이 늘고, 각 서비스가 인가 서버에 클라이언트로 등록되어야 합니다. 하지만 보안과 감사가 중요한 아키텍처에서는 원칙적 선택입니다.

페더레이션 ID와 Cross App Access

서비스가 보안 도메인을 넘나들 때 체인 시나리오는 훨씬 복잡해집니다. MyCompany 도메인의 사용자를 대신해 External Provider 도메인의 Service C를 호출해야 한다면, 한 인가 서버가 발급한 토큰을 다른 서버가 자동으로 수용하지 않으므로 신뢰 경계 설정이 필요합니다.

도메인이 늘어날수록 양자 간 신뢰 관계의 매트릭스가 관리 불가능해집니다. 이를 해결하기 위한 Cross App Access(XAA)는 Identity Assertion JWT Authorization Grant를 구현하며, 교차 도메인 교환에 엔터프라이즈 IdP를 중재자로 도입합니다.

XAA 흐름은 4개 당사자로 구성됩니다.

• Requesting App: 다른 도메인 리소스에 접근해야 하는 애플리케이션

• Enterprise IdP: 직원을 인증하고 교차 앱 정책을 관리하는 ID 제공자

• Resource App: 보호된 API를 소유한 애플리케이션

• Resource Authorization Server: Resource App의 보호 API용 액세스 토큰을 발급하는 인가 서버

IdP가 XAA 정책 확인을 통해 "이 사용자를 대신해 Resource App 접근이 허용되는지" 판단하고, 허용 시 ID-JAG(Identity Assertion JWT)를 반환합니다. 일반 토큰 교환과의 결정적 차이는 이 정책 결정 단계에서 관리자가 어떤 앱이 어떤 리소스에 도달할 수 있는지 명시적으로 구성한다는 점입니다.

AI 에이전트와 토큰 교환의 미래

여러 서비스와 제공자에 걸쳐 사용자를 대신해 작업을 오케스트레이션하는 AI 에이전트는 본질적으로 위임 체인입니다. 토큰 교환 메커니즘이 그 체인을 감사 가능하고 인가되며 사용자 의도에 스코프되도록 만드는 보안 기반을 제공합니다.

Auth0의 Token Vault가 대표 사례입니다. 여러 제공자에 걸쳐 사용자를 대신해 제3자 API를 호출하는 AI 에이전트 시나리오용으로, 토큰 교환에 안전한 저장과 자동 수명 주기 관리를 추가합니다. 결과 토큰에 AI 에이전트를 식별하는 act 클레임을 포함해 어떤 에이전트가 어떤 사용자를 대신해 어떤 서비스에 접근했는지 감사 추적을 생성합니다. 이는 무엇이 자동화를 촉발했는지 알아야 하는 엔터프라이즈 컴플라이언스에 필수적입니다.

On-Behalf-Of(OBO) 토큰 교환은 서비스 체인 시나리오용으로 위임 패턴을 직접 구현합니다. 최대 5단계 위임 체인 중첩을 지원하며, 각 토큰은 sub(사용자 정체성 유지), aud(대상 서비스 스코프), 중첩 act(관여 서비스 체인 기록) 클레임을 보유합니다.

의사결정 가이드

토큰 교환은 단일 솔루션이 아니라 패턴의 집합입니다. 보존할 컨텍스트와 넘어야 할 신뢰 경계에 따라 선택이 달라집니다.

• 관리자 임퍼소네이션: 문제 해결 시 사용자가 보는 화면을 그대로 봐야 할 때

• 프로토콜 전환: 마이그레이션 중 레거시와 현대 ID 시스템을 잇는 다리가 필요할 때

• 위임: 서비스 체인이 완전한 감사 가능성과 함께 사용자 컨텍스트를 요구할 때

• Cross App Access / Identity Chaining: 위임이 여러 보안 도메인에 걸칠 때

• Token Vault: AI 에이전트가 사용자를 대신해 제3자 API에 대한 관리된 접근이 필요할 때

한 가지 분명한 것은, AI 에이전트 시대에 접어들면서 토큰 교환은 더 이상 특수한 사용 사례의 도구가 아니라 분산 시스템과 자율 에이전트의 보안을 떠받치는 핵심 프리미티브가 되었다는 점입니다.

---

📚 출처

• https://news.hada.io/topic?id=30164