Las múltiples caras del intercambio de tokens en OAuth 2.0

• Un mecanismo basado en estándares para convertir un token de seguridad en otro, definido en la especificación de extensión de OAuth 2.0 RFC 8693
• Convierte al servidor de autorización en un Security Token Service (STS), para validar el token enviado por el cliente y emitir uno nuevo adecuado para otro contexto, destino (audience) u objetivo
• Su funcionamiento se divide en dos modos principales: impersonation e impersonation delegada (delegation)
• Cada caso de uso distinto —como impersonación administrativa, transición de protocolo, encadenamiento de servicios e identidad federada— tiene sus propios trade-offs e implicaciones de seguridad
• Con la expansión de los agentes de IA, las tareas que cruzan múltiples servicios y proveedores se convierten esencialmente en cadenas de delegación, lo que hace aún más importante el intercambio de tokens

---

¿Qué es el intercambio de tokens (Token Exchange)?

• El cliente envía un subject_token (el token que representa al usuario o entidad que origina la solicitud) y, opcionalmente, un actor_token (la parte que realiza el intercambio), y recibe un nuevo token adecuado para el contexto de destino
• Reenviar el token existente tal cual o crear uno nuevo desde cero puede parecer intuitivo, pero ambos enfoques provocan problemas serios; esta especificación se creó para resolverlos

• Dos modos básicos de operación

  • Impersonation: la parte solicitante recibe un token imposible de distinguir del sujeto original; el servicio downstream no puede saber si la solicitud viene del usuario real o de quien lo está impersonando
  • Delegation: preserva la identidad de ambos sujetos; mediante el claim act (actor) incluido en el nuevo token, el servicio downstream puede reconocer tanto al usuario como al ejecutor delegado
  • La impersonation es poderosa pero opaca; la delegation tiene restricciones, pero permite auditoría — esta elección define la postura de seguridad y la capacidad de trazabilidad

Impersonación administrativa (Administrative Impersonation)

• Un caso típico es cuando un ingeniero de soporte necesita ver exactamente la misma pantalla, con los mismos permisos y acceso a datos, para diagnosticar por qué un dashboard del cliente muestra información incorrecta
• El administrador intercambia su token por uno que representa la identidad del cliente; el token resultante incluye el claim sub, los scopes y la audience del cliente, por lo que, desde la perspectiva de la aplicación, la solicitud se ve como enviada por el cliente
• En este caso, la solicitud usa solo subject_token (el usuario a impersonar) y no proporciona actor_token, porque el objetivo es una impersonación completa

• El problema de perder la pista de auditoría

  • Como se trata de impersonación real, se pierde la pista de auditoría sobre quién realizó realmente la acción
  • Por eso debe ir siempre acompañada de un mecanismo externo de logging que registre quién, cuándo y por qué inició el intercambio; de lo contrario, la resolución de problemas puede abrir un vacío de seguridad

Gestión de transición de protocolo (Managing Protocol Transition)

• En entornos donde aún existen sistemas legacy y protocolos antiguos, aparece el escenario de operar en paralelo mientras se migra de autenticación SAML a OpenID Connect (OIDC)
• Un servicio que autentica al usuario con SAML intercambia una SAML assertion por un token de acceso OAuth 2.0; el servidor de autorización valida el artefacto SAML recibido y emite un token de acceso estándar que entienden los sistemas downstream

• Parámetro subject_token_type

  • Identifica el formato del token entrante; RFC 8693 define varios identificadores de tipo de token
    • SAML 2.0 assertion: urn:ietf:params:oauth:token-type:saml2
    • Token JWT: urn:ietf:params:oauth:token-type:jwt
  • Esto permite que el servidor de autorización acepte tokens de distintas familias de protocolos y los normalice a un formato coherente para servicios modernos
• Es un patrón que aparece cuando dos organizaciones con stacks de identidad distintos deben interoperar antes de completar una migración total, por ejemplo tras una fusión o adquisición; el usuario sigue autenticándose como siempre y el sistema transforma las credenciales al formato requerido por el servicio consumidor

Encadenamiento de llamadas de servicio (Chaining Service Calls)

• En una arquitectura de microservicios, si Service A procesa la solicitud del usuario y luego debe llamar a Service B en su nombre, y después Service B debe llamar a Service C, la pregunta clave es qué credenciales debe usar cada servicio para la siguiente llamada

• Opción 1 — usar las credenciales propias del servicio

  • Service A ignora el contexto del usuario y llama a Service B con sus propias credenciales de cliente; esto es apropiado para llamadas entre servicios donde no hace falta el contexto del usuario, como procesamiento por lotes, verificación del estado del sistema o sincronización de datos
  • Pero cuando el usuario sí importa, Service B no puede aplicar autorización a nivel usuario — no sabe qué usuario originó la solicitud y no puede verificar permisos de acceso; se pierde el contexto de seguridad

• Opción 2 — el servicio impersona al usuario

  • Service A reenvía el token original del usuario a Service B o lo intercambia por uno indistinguible del usuario; Service B lo trata como una solicitud emitida por el usuario y aplica autorización a nivel usuario
  • Service B no puede distinguir entre una acción directa del usuario y una acción delegada por Service A; si Service A se ve comprometido, puede realizar cualquier llamada dentro de los permisos del usuario, y no es posible aplicar distintos niveles de confianza a solicitudes directas y por proxy — se preserva el contexto del usuario, pero se pierde el contexto del servicio

• Opción 3 — actuar en nombre del usuario (Delegation)

  • Service A intercambia el token del usuario por uno nuevo que identifica tanto al usuario (subject) como a Service A (actor); el claim act del token resultante comunica: "solicitud sobre el usuario X, realizada por Service A"
  • Este es el modelo de delegación que RFC 8693 fue diseñado principalmente para soportar, y permite que Service B tome decisiones de autorización más refinadas — si Service A intenta una acción no autorizada por el usuario, la solicitud falla
  • El claim act puede anidarse (nestable); si Service B llama a Service C, la cadena de delegación se extiende y proporciona una pista de auditoría completa
  • El trade-off es la complejidad — cada salto requiere intercambio de tokens, lo que aumenta la latencia, y cada servicio debe estar registrado como cliente en el servidor de autorización; aun así, en arquitecturas donde la seguridad y la auditoría son críticas, es la opción más sólida

Intercambio de tokens e identidad federada

• Cuando los servicios cruzan dominios de seguridad (por ejemplo, un servicio provisto por una organización tercera), el escenario de encadenamiento se vuelve mucho más complejo
  • Service A tiene un token para acceder a Service B en nombre de un usuario dentro del dominio de seguridad de MyCompany
  • Service B debe llamar a Service C, protegido en el dominio de External Provider, y necesita un token de acceso para hacerlo
• El token emitido por el servidor de autorización de MyCompany no tiene significado en el dominio de External Provider — un token emitido por un servidor de autorización no es aceptado automáticamente por otro; los límites de confianza existen para limitar el blast radius

• Límites de una configuración federada

  • El servidor de autorización de External Provider debe configurarse para aceptar los tokens del dominio MyCompany como subject_token válidos; esto requiere confianza previa entre dominios y mapeo de identidades, mediante intercambio de metadatos, validación de certificados o configuración directa
  • A medida que aumentan los dominios —integraciones empresariales, ecosistemas SaaS, multi-cloud— la matriz de relaciones de confianza bilaterales se vuelve imposible de administrar

• Cross App Access e Identity Chaining

  • Para resolver este problema de escalabilidad surge Cross App Access (XAA), que implementa Identity Assertion JWT Authorization Grant e introduce un IdP empresarial como mediador en el intercambio entre dominios
  • La idea es aprovechar que el IdP ya conoce la relación entre ambas aplicaciones y el usuario; en vez de que cada par de dominios establezca confianza bilateral, las decisiones de acceso se concentran en el IdP

  • Los 4 participantes del flujo XAA

    • Requesting App: la aplicación del dominio MyCompany (o un agente de IA) que necesita acceder a recursos de otro dominio
    • Enterprise IdP: el proveedor de identidad del dominio MyCompany que autentica a los empleados y administra las políticas cross-app
    • Resource App: la aplicación del dominio External Provider que posee la API protegida
    • Resource Authorization Server: el servidor de autorización que emite tokens de acceso para la API protegida de Resource App

  • Flujo XAA paso a paso

    • El empleado inicia sesión en Requesting App con SSO y obtiene un ID token del IdP
    • Requesting App vuelve a enviar ese ID token al IdP para solicitar una aserción de identidad cross-domain (ID-JAG, un JWT especial con scope para uso entre apps)
    • El IdP revisa la política XAA — determina si se permite acceder a Resource App en nombre de ese usuario; si se permite, devuelve el ID-JAG
    • Requesting App presenta el ID-JAG al servidor de autorización de Resource App
    • El servidor de autorización de Resource App valida el ID-JAG usando la clave pública del IdP vía OIDC discovery y emite un token de acceso
    • Requesting App llama a la API de Resource App con ese token de acceso
  • La diferencia decisiva frente al intercambio de tokens común es que, en el paso 3, el IdP hace cumplir la decisión de política — el administrador configura explícitamente qué apps pueden alcanzar qué recursos, lo que da visibilidad y control a TI y evita al usuario flujos repetidos de consentimiento
  • Identity Chaining es el patrón más amplio en el que una aserción de identidad del usuario fluye de forma estandarizada desde la autenticación inicial hasta todos los servicios downstream; XAA es una implementación basada en primitivas de OAuth
  • Es especialmente relevante en escenarios de agentes de IA donde una sola solicitud del usuario dispara llamadas a servicios de múltiples proveedores externos

Intercambio de tokens y Auth0

• Auth0 implementa el intercambio de tokens con mecanismos que cubren distintos puntos del espectro descrito anteriormente

• Custom Token Exchange

  • Implementa RFC 8693 en el endpoint /oauth/token de Auth0 y ofrece control total del desarrollador sobre la lógica de validación
  • Define un Token Exchange Profile que asigna un URI de subject_token_type a una Action personalizada; cuando llega una solicitud, Auth0 invoca el código de la Action para validar el token, aplicar reglas de autorización y vincular al usuario dentro del tenant
  • Como Auth0 trata subject_token como una cadena opaca, puede aceptar cualquier formato — JWT de otro IdP, una SAML assertion legacy o un token propietario de una API partner — por lo que sirve para transición de protocolo y federación personalizada

• Token Vault

  • Pensado para escenarios de agentes de IA que llaman APIs de terceros en nombre del usuario a través de múltiples proveedores; añade almacenamiento seguro y gestión automática del ciclo de vida al intercambio de tokens
  • Después de autenticarse, el usuario conecta cuentas (Google, GitHub, Slack, Microsoft, etc.); Token Vault almacena los tokens de forma segura y maneja automáticamente la renovación, mientras el agente de IA recupera del almacén un token de acceso válido mediante intercambio de tokens
  • El token resultante incluye un claim act que identifica al agente de IA — esto genera una pista de auditoría sobre qué agente accedió a qué servicio en nombre de qué usuario, algo esencial para compliance empresarial cuando se necesita saber qué disparó la automatización

• On-Behalf-Of (OBO) Token Exchange

  • Implementa directamente el patrón de delegación para escenarios de cadena de servicios; un servicio intermedio intercambia el token entrante del usuario por uno nuevo con scope para la API downstream y se añade a la cadena de delegación mediante el claim act
  • Soporta hasta 5 niveles de anidación en la cadena de delegación; cada token contiene los claims sub (preserva la identidad del usuario), aud (scope para el servicio objetivo) y act anidado (registra la cadena de servicios involucrados)

• Cross App Access (XAA)

  • Pensado para escenarios de identidad federada donde la aplicación solicitante debe llamar una API de recursos protegida por otro servidor de autorización; implementa la extensión OAuth Identity Assertion Authorization Grant
  • Auth0 actúa como Resource Authorization Server — Requesting App envía el ID token del usuario a un IdP como Okta para recibir un ID-JAG, y el IdP solo emite la aserción si el administrador configuró la conexión cross-app en Admin Console
  • Luego Requesting App presenta el ID-JAG a Auth0, que lo valida mediante OIDC discovery y emite un token de acceso con scope, dando a TI visibilidad centralizada sobre el intercambio de datos entre aplicaciones

Elegir el enfoque correcto

• El intercambio de tokens no es una única solución, sino un conjunto de patrones; la elección depende del contexto que se quiera preservar y de los límites de confianza que haya que cruzar
  • Impersonación administrativa: cuando hay que ver exactamente lo mismo que ve el usuario para resolver un problema
  • Transición de protocolo: cuando se necesita un puente entre sistemas de identidad legacy y modernos durante una migración
  • Delegation: cuando una cadena de servicios requiere contexto del usuario con auditoría completa
  • Cross App Access / Identity Chaining: cuando la delegación abarca múltiples dominios de seguridad
  • Token Vault: cuando un agente de IA necesita acceso administrado a APIs de terceros en nombre del usuario
• Los agentes de IA que orquestan tareas en nombre del usuario a través de múltiples servicios y proveedores son, en esencia, cadenas de delegación; los mecanismos de intercambio de tokens proporcionan la base de seguridad para que esa cadena sea auditable, autorizada y limitada a la intención del usuario