La frontera: identidad de máquinas y credenciales verificables

Dos fronteras a la vez

Cerramos el módulo de protocolos mirando hacia adelante. La identidad está siendo empujada en dos direcciones al mismo tiempo, y ambas están remodelando los estándares. Una frontera son las máquinas: los sistemas modernos son marañas de microservicios, contenedores y funciones que deben autenticarse entre sí constantemente, a una escala y velocidad que ningún modelo de login humano anticipó. La otra son las personas: un movimiento para devolver a los individuos el control de sus propias credenciales, llevadas en una wallet, presentadas en sus términos. En crudo: máquinas probando quiénes son, y humanos llevando su identidad en una wallet.

Ninguna es ciencia ficción — el lado de las cargas de trabajo está en producción en grandes empresas hoy, y el lado de las wallets lo están desplegando gobiernos. Pero ambas se mueven rápido, así que trata este artículo como un mapa de hacia dónde va el disco, no como una referencia asentada. Tomaremos primero la frontera de las máquinas, luego la humana.

Por qué está pasando ahora

Tres fuerzas convergen para que esto sea la frontera y no una nota al pie:

• Escala y arquitectura. Los sistemas cloud-native reemplazaron unas pocas aplicaciones grandes por miles de servicios pequeños y cargas de trabajo efímeras, así que la autenticación máquina-a-máquina pasó de ser un caso límite al volumen dominante de autenticación en un sistema. Los modelos de login humano simplemente no encajan con esa forma.
• El patrón de las brechas. Los post-mortems de incidentes siguen aterrizando en las mismas causas: un bearer token robado reusado en otra parte, un secreto de vida larga filtrado en un repositorio, una sesión que siguió válida mucho después de que debió morir. Token exchange, DPoP, SPIFFE y CAEP atacan cada uno uno de esos modos de fallo exactos.
• La explosión de identidad no humana — incluidos los agentes de IA. Las cuentas de servicio, las cargas de trabajo y ahora los agentes de IA autónomos actuando en nombre de usuarios ya superan a las identidades humanas por grandes múltiplos, y cada uno necesita autenticarse, acotarse y revocarse como cualquiera. Dar a los actores no humanos identidad de primera clase, de vida corta y mínimo privilegio se ha vuelto urgente en lugar de opcional.
• Privacidad y regulación. Del lado humano, la regulación y la desconfianza pública hacia los data brokers empujan hacia modelos donde las personas presentan pruebas en lugar de que los proveedores broker-een sus datos en cada transacción — exactamente lo que habilitan las wallets y las credenciales verificables.

El problema de los microservicios

Una sola solicitud de usuario a una app moderna puede ramificarse a través de docenas de servicios — un API gateway llama a un servicio de pedidos, que llama a pagos, que llama a un libro mayor. ¿Cómo sabe el servicio de pagos que la llamada realmente representa a la usuaria María, actuando dentro de sus permisos, y no a un vecino confundido o comprometido? La respuesta ingenua — reenviar el access token original del usuario a cada servicio — es justo el anti-patrón: ese token está sobrepoderado para cualquier salto único, y como es un bearer token, cualquiera que lo capture en cualquier punto de la cadena puede reusarlo en todas partes. Los estándares de la frontera atacan ambas mitades de ese problema.

Token exchange: mínimo privilegio por salto

OAuth Token Exchange (RFC 8693) permite a un servicio intercambiar el token que tiene por uno distinto — con menor scope, re-dirigido a la audiencia del siguiente servicio, y opcionalmente llevando semántica de delegación (“el servicio A actúa por la usuaria María”) o impersonación. Cada salto solicita un token acuñado para solo el siguiente servicio y solo el scope que necesita.

sequenceDiagram
  accTitle: OAuth token exchange entre microservicios
  accDescr: Un usuario llama al servicio de pedidos con un access token amplio. Antes de llamar al servicio de pagos downstream, el servicio de pedidos envía ese token al endpoint de token-exchange del authorization server y solicita un nuevo token acotado solo al servicio de pagos. El authorization server devuelve un token de menor scope y re-dirigido. El servicio de pedidos luego llama a pagos con ese token estrecho, así que cada servicio recibe solo el privilegio que necesita y un token capturado entre saltos está acotado a una sola audiencia.
  actor U as Usuaria (María)
  participant O as Servicio de pedidos
  participant AS as Authorization Server
  participant P as Servicio de pagos
  U->>O: Solicitud (token de usuario amplio)
  O->>AS: Token exchange: "dame un token solo para pagos"
  AS->>O: Token de menor scope (aud=pagos)
  O->>P: Llamar a pagos (token estrecho)
  P->>O: Resultado

La recompensa es mínimo privilegio en lo profundo del sistema, no solo en la puerta de entrada: un token capturado entre los servicios de pedidos y pagos está acotado solo a pagos e inútil contra el libro mayor, y la cadena de delegación es explícita y auditable. Es el principio de JML de “solo el acceso que la tarea necesita” empujado hasta el nivel de una sola llamada entre servicios.

El RFC 8693 distingue dos modos que vale conocer. En la delegación, el nuevo token registra que el servicio actúa en nombre de María — ambas identidades permanecen visibles, que es el default honesto y auditable. En la impersonación, el token simplemente se vuelve María, sin rastro del servicio intermediario. La delegación preserva la cadena de custodia y es lo que normalmente quieres; la impersonación es ocasionalmente necesaria pero borra quién hizo realmente la llamada, así que recurre a ella con moderación y registra mucho cuando lo hagas.

DPoP: volver inútiles los tokens robados

El token exchange estrecha qué puede hacer un token; DPoP (Demonstrating Proof-of-Possession, RFC 9449) estrecha quién puede usarlo. La debilidad central de cualquier bearer token es que la posesión equivale a la autoridad — róbalo y eres él. DPoP ata el token a su emisor: el cliente genera un par de claves, el token se vincula a esa clave pública, y en cada solicitud el cliente firma una pequeña prueba con la clave privada. Un servidor acepta el token solo junto a una prueba válida, así que un token sacado de un log o de una llamada interceptada es inerte sin la clave privada que nunca abandonó al cliente legítimo.

Este es el primo ligero del mutual TLS que vimos entre los veteranos — logra la atadura al emisor en la capa de aplicación, sobre HTTPS ordinario, sin aprovisionar un certificado a cada cliente. Es la respuesta a la advertencia de “los bearer tokens son robables” que marcamos en el artículo de tokens, y está pasando de vanguardia a esperado para APIs de alto valor. Si interiorizas una regla de todo este módulo, que sea esta: un bearer token es efectivo, y DPoP es el chip-y-PIN que vuelve inútil uno robado.

SPIFFE y el service mesh: identidad para las cargas de trabajo

El token exchange y DPoP aseguran las llamadas; SPIFFE asegura a los llamadores. La pregunta más profunda en un mundo de microservicios es: ¿cómo tiene una carga de trabajo una identidad siquiera? La respuesta vieja — hornear un secreto compartido o una API key en cada servicio — es una maraña de credenciales de vida larga que nadie rota. SPIFFE (Secure Production Identity Framework for Everyone) la reemplaza con una identidad de carga de trabajo criptográfica: cada servicio obtiene un SPIFFE Verifiable Identity Document (un SVID, un certificado X.509 o un JWT) que lo nombra, emitido y rotado automáticamente por el runtime (su implementación, SPIRE).

En un service mesh como Istio, esta es la maquinaria que permite que cada llamada servicio-a-servicio corra sobre mutual TLS con ambos lados criptográficamente identificados — sin que los desarrolladores gestionen un solo certificado. SPIFFE es, en efecto, un directorio y una PKI para máquinas: donde Active Directory responde “quién es este usuario”, SPIFFE responde “qué carga de trabajo es esta”, con credenciales medidas en minutos en lugar de años. A medida que las identidades no humanas superan a los humanos por grandes múltiplos, esta capa de identidad de cargas de trabajo se vuelve tan fundacional como el directorio humano. Dicho sin rodeos: dentro de unos años, “¿quién puede acceder a esto?” significará tan a menudo una carga de trabajo como una persona, y los sistemas que responden esa pregunta para las máquinas se están construyendo justo ahora.

Federación de identidad de cargas de trabajo

Un pariente cercano resuelve la versión cross-cloud del mismo problema. La federación de identidad de cargas de trabajo permite que una carga de trabajo en un entorno se autentique a otro usando una afirmación de su propia identidad basada en OIDC y de vida corta, en lugar de un secreto almacenado de vida larga. Un job de CI/CD o una función en la nube A prueba qué es y se le otorga una credencial temporal en la nube B — sin API key que filtrar, sin secreto que rotar. Es el mismo instinto de “eliminar los secretos permanentes” que SPIFFE, aplicado a través de fronteras de confianza, y rápidamente se vuelve la forma por defecto de conectar sistemas cloud.

Evaluación continua del acceso: cerrar la brecha de revocación

Recuerda el problema sin resolver de el artículo de tokens: un token autocontenido sigue válido hasta que expira, así que revocar el acceso a mitad de sesión es difícil. La respuesta de la frontera es volver el acceso evaluado continuamente en lugar de decidido una vez en el login. El Shared Signals Framework y su CAEP (Continuous Access Evaluation Profile) permiten a los proveedores de identidad y a las aplicaciones intercambiar eventos de seguridad en tiempo real — “esta sesión fue revocada”, “este dispositivo ahora no cumple”, “el riesgo de este usuario acaba de dispararse”.

flowchart LR
  accTitle: Evaluación continua del acceso vía shared signals
  accDescr: Un proveedor de identidad detecta un evento de seguridad, como una sesión siendo revocada, un dispositivo volviéndose no conforme, o el nivel de riesgo de un usuario subiendo. A través del Shared Signals Framework envía una señal de evento de seguridad a cada aplicación suscrita en tiempo real. Cada aplicación recibe la señal y de inmediato reevalúa o termina la sesión afectada, en lugar de seguir confiando en un token ya emitido hasta que expira.
  EV[Evento de seguridad<br/>sesión revocada · riesgo de dispositivo · anomalía] --> IDP[Proveedor de identidad]
  IDP -->|envía señal| A1[App A reevalúa / termina sesión]
  IDP -->|envía señal| A2[App B reevalúa / termina sesión]
  IDP -->|envía señal| A3[App C reevalúa / termina sesión]

El cambio es conceptual: del acceso como un hecho establecido en el login al acceso como una suscripción en vivo que cualquier parte puede actualizar. Es una respuesta directa, a escala de ecosistema, a la debilidad de revocación de los tokens sin estado — y es cómo una sesión comprometida puede matarse en muchas apps en segundos en lugar de persistir hasta expirar. Espera que se extienda dondequiera que “válido hasta que expira” sea un default demasiado peligroso.

La otra frontera: credenciales verificables y wallets

Ahora el lado humano. Hoy, cuando pruebas algo sobre ti — tu edad, tu título, tu licencia profesional — normalmente lo haces dejando que un proveedor responda por ti en tiempo real, lo que significa que ese proveedor ve cada transacción y guarda los datos. Las credenciales verificables (VC) invierten esto. Un emisor (un gobierno, universidad, empleador) te da una credencial firmada y a prueba de manipulación; la guardas en una wallet en tu dispositivo; y cuando un verificador necesita una prueba, la presentas directamente, y él comprueba la firma del emisor sin contactar al emisor. Tú — el holder — estás en el medio, en control.

Pantalla completa

Dos bloques de construcción hacen esto funcionar. Una credencial verificable (W3C VC Data Model) es la afirmación firmada en sí. Un identificador descentralizado (DID) (W3C DID) es un identificador que el sujeto controla — anclado a un registro o ledger público en lugar de emitido y poseído por un único proveedor — de modo que la firma del emisor puede verificarse contra una clave que gobierna el holder, no un vendor. La combinación habilita identidad genuinamente controlada por el usuario y respetuosa de la privacidad: el holder decide qué presentar, a quién y cuándo.

El problema abierto: revocación a escala

El triángulo de confianza tiene una trampa que refleja el problema de revocación de tokens: si un verificador comprueba una credencial sin contactar al emisor, ¿cómo se revoca una credencial filtrada, vencida o retirada? La respuesta emergente son las status lists — una lista publicada, compacta y respetuosa de la privacidad (a menudo un bitstring) que un verificador consulta para ver si una credencial ha sido revocada, sin revelar cuál credencial se está comprobando. La revocación, la rotación de claves del emisor y la recuperación de la wallet (¿qué pasa cuando pierdes el teléfono que guarda tus credenciales?) son los problemas sin glamour que están entre los pilotos de hoy y la adopción masiva — y son justo el tipo de detalle que separa un demo de un sistema desplegable.

Divulgación selectiva: probar menos

Una capacidad calladamente radical de este modelo es la divulgación selectiva — presentar solo el hecho específico que un verificador necesita, no la credencial entera. Con la criptografía correcta (y, cada vez más, técnicas de conocimiento cero), un holder puede probar “soy mayor de 18” a partir de una credencial de identidad gubernamental sin revelar su fecha de nacimiento, nombre ni número de documento. Compáralo con entregar una foto de tu pasaporte, que lo expone todo. Minimizar lo que se divulga es la frontera de privacidad que el modelo de wallet desbloquea, y es una mejora genuina sobre tanto las contraseñas como el login federado de hoy.

OID4VCI y OID4VP: el puente desde OIDC

El riesgo con un nuevo paradigma de identidad es que reinvente todo y no se integre con nada. La comunidad de estándares lo evitó tendiendo un puente entre las credenciales verificables y el mundo OIDC que pasamos este módulo aprendiendo. OpenID for Verifiable Credential Issuance (OID4VCI) define cómo una wallet obtiene una credencial de un emisor; OpenID for Verifiable Presentations (OID4VP) define cómo la wallet presenta una a un verificador. Ambos montan sobre la maquinaria de OAuth/OIDC — endpoints, tokens, flujos — para que el enorme ecosistema existente pueda emitir y consumir credenciales verificables sin empezar de cero. Este pragmatismo es por lo que el modelo de wallet tiene impulso real, más visiblemente en la EU Digital Identity Wallet (bajo eIDAS 2.0) y la licencia de conducir móvil ISO (mDL, ISO 18013-5).

El hilo conductor de Zero Trust

Da un paso atrás y cada tecnología de la frontera aquí es, en el fondo, un detalle de implementación de una idea: Zero Trust. El principio — codificado en NIST SP 800-207 — es “nunca confíes, siempre verifica”: sin confianza implícita por la ubicación de red, cada solicitud autenticada y autorizada, mínimo privilegio en todas partes, y asume la brecha. Los estándares de la frontera son cómo esa filosofía se vuelve plomería asequible:

• Token exchange por salto = mínimo privilegio por solicitud, no por sesión.
• DPoP y mTLS / SPIFFE = verifica al emisor, nunca confíes en la mera posesión.
• CAEP / Shared Signals = reverifica continuamente, nunca confíes en una decisión pasada para siempre.
• Identidades de carga de trabajo de vida corta = asume que cualquier credencial puede estar comprometida, así que hazla expirar rápido.

Zero Trust es la filosofía (la vimos en ciberseguridad centrada en la identidad); estos protocolos son la maquinaria que vuelve “verifica cada vez” lo bastante barato como para hacerlo de verdad a escala. Cuando alguien dice “estamos haciendo Zero Trust”, este stack es buena parte de lo que debería significar — de lo contrario es un eslogan sin plomería.

Hype versus realidad

Una frontera atrae hype, así que vale ser claro sobre la madurez:

• En producción ahora: token exchange, DPoP, SPIFFE/SPIRE y la federación de identidad de cargas de trabajo están desplegados a escala por grandes organizaciones de ingeniería. La frontera de las máquinas es real y llega rápido.
• Emergiendo rápido: CAEP / Shared Signals está más allá de la teoría, con proveedores importantes enviando soporte, pero aún no es ubicuo.
• Temprano pero impulsado por gobiernos: las credenciales verificables y las wallets están madurando, con mandatos serios del sector público (la wallet de la UE, las mDL) impulsando la adopción — pero la interoperabilidad, la revocación a escala y la UX todavía se están trabajando.

La postura honesta: la frontera de las cargas de trabajo es un tema de “apréndelo ahora, lo usarás pronto”; la frontera de las wallets es un tema de “obsérvalo de cerca, ya viene”. Ambas valen entenderse, ninguna está terminada, y eso es justo lo que las vuelve la frontera.

Recapitulación

La frontera empuja el mínimo privilegio y el control del usuario más lejos de lo que lo hicieron los protocolos centrales:

1. Token exchange (RFC 8693) reduce el scope y re-dirige los tokens por salto, para que las llamadas entre microservicios lleven mínimo privilegio en lugar de reenviar un token sobrepoderado.
2. DPoP (RFC 9449) ata el token a su emisor para que uno robado sea inútil sin la clave privada del cliente — prueba de posesión ligera sobre HTTPS plano.
3. SPIFFE / SPIRE da a las cargas de trabajo identidades criptográficas y auto-rotadas (SVIDs) — un directorio y una PKI para máquinas — que impulsan el mutual TLS en el service mesh; la federación de identidad de cargas de trabajo lo extiende entre nubes sin secretos permanentes.
4. CAEP / Shared Signals vuelve el acceso una suscripción en vivo, enviando eventos en tiempo real para que las sesiones se revoquen en pleno vuelo — cerrando la brecha de revocación de los tokens sin estado.
5. Credenciales verificables + DIDs ponen afirmaciones firmadas en la wallet de un usuario, presentadas a verificadores que confían en la firma del emisor sin una llamada en vivo — con divulgación selectiva para la privacidad.
6. OID4VCI / OID4VP tienden un puente del modelo de wallet sobre OAuth/OIDC, por lo que tiene impulso real (wallet de la UE, mDL). La nueva capa se une al stack; no lo reemplaza — la misma lección que cada era de este módulo ha enseñado, de LDAP a la wallet.
7. Zero Trust es el hilo conductor: token exchange, DPoP/SPIFFE, CAEP e identidad de carga de trabajo de vida corta son cómo “nunca confíes, siempre verifica” se vuelve plomería asequible y no un eslogan.

Ejercicios prácticos

Estos son prácticos — hazlos, no solo los leas:

1. Rastrea el mínimo privilegio (caso de uso). Una solicitud fluye gateway → pedidos → pagos → libro mayor. Muestra dónde insertarías el token exchange y qué audiencia/scope debería llevar el token de cada salto, luego explica qué podría y qué no podría hacer un token robado entre pedidos y pagos.
2. Justifica DPoP (caso de uso). Un equipo dice “usamos HTTPS, así que el robo de tokens no es preocupación”. Explica la brecha que DPoP cierra y que TLS no, y cuándo lo exigirías frente a bearer tokens planos.
3. Diseña identidad de cargas de trabajo (caso de uso). Veinte microservicios actualmente se autentican entre sí con una API key compartida en una variable de entorno. Describe cómo SPIFFE/SPIRE cambia eso y tres riesgos concretos que elimina.
4. Cierra la brecha de revocación (caso de uso). Un usuario es despedido y debe perder acceso a diez apps SaaS de inmediato, pero todas usan JWT de 15 minutos. Explica cómo CAEP / Shared Signals lo resuelve y qué debe soportar cada app.
5. Recorre el triángulo (caso de uso). Usando el diagrama del triángulo de confianza, describe emitir una credencial de “mayor de 18” y presentarla al sitio de verificación de edad de un bar con divulgación selectiva — nombra quién firma, quién la guarda, quién verifica, y exactamente qué dato aprende y no aprende el verificador.
6. Mapéalo a Zero Trust (caso de uso). Toma un fallo real — un secreto de CI filtrado, o un empleado despedido cuyo JWT sigue válido — y nombra qué tecnología de la frontera lo aborda y qué principio de Zero Trust (“verifica al emisor”, “mínimo privilegio por solicitud”, “reverifica continuamente”, “asume la brecha”) encarna.

Tres preguntas para autoevaluarte

1. Explica cómo el token exchange y DPoP atacan dos debilidades distintas de reenviar un bearer token a través de una cadena de microservicios.
2. ¿Por qué se describe a SPIFFE como “un directorio para máquinas”, y qué problema con los secretos compartidos resuelve la rotación automática de SVIDs?
3. En el modelo de credenciales verificables, ¿cómo puede un verificador confiar en una credencial sin contactar nunca al emisor, y qué le permite la divulgación selectiva al holder evitar revelar?