La frontera: identidad de máquinas y credenciales verificables

Cuarenta minutos de más

Un viernes por la tarde le roban el portátil a Sara López en una cafetería. Llama al servicio de ayuda desde el móvil de una amiga y en diez minutos su cuenta está desactivada y sus sesiones en el proveedor de identidad, revocadas. El lunes, el equipo de seguridad revisa los logs y descubre que el navegador del ladrón siguió llamando a la API de gastos durante cuarenta minutos más. El access token que tenía era un JWT autocontenido válido durante una hora, y la API no tenía forma de saber que la cuenta que lo respaldaba ya no existía. De paso encuentran algo peor: un trabajo de compilación del pipeline de CI se autentica contra producción con una clave de API que lleva tres años en un fichero de configuración.

Ninguno de los dos problemas es exótico, y ninguno lo resuelven por sí solos los protocolos principales. Ahí entra la frontera. Cerramos el módulo de protocolos mirando hacia delante, y la identidad se está estirando en dos direcciones a la vez. Una frontera son las máquinas: los sistemas modernos son un enjambre de microservicios, contenedores y funciones que se autentican entre sí sin parar, a una escala y una velocidad que ningún modelo de inicio de sesión humano previó. La otra son las personas: un movimiento para devolver a cada uno el control de sus credenciales, guardadas en una cartera y presentadas en sus propios términos.

Ninguna es ciencia ficción. La parte de las cargas de trabajo está en producción hoy en empresas grandes, y los gobiernos están desplegando la de las carteras. Las dos siguen moviéndose deprisa, así que lee este artículo como un mapa de hacia dónde van las cosas y no como una referencia cerrada. Comparten una idea: reducir la confianza permanente. En el lado de las máquinas, eso significa tokens con alcance para un solo salto y atados a quien los envía, e identidades que duran minutos. En el lado de las personas, significa credenciales que controla y revela de forma selectiva su titular, en lugar de un proveedor que lo guarda y lo intermedia todo.

Por qué ahora

Varias fuerzas están llevando estas ideas de la nota al pie a la primera línea. Los sistemas nativos de la nube sustituyeron unas pocas aplicaciones grandes por miles de servicios pequeños y cargas de trabajo efímeras, así que la autenticación entre máquinas pasó de ser un caso raro a ser la mayor parte de la autenticación de un sistema, y los modelos de inicio de sesión humano no encajan en esa forma. Los informes de incidentes no dejan de llegar a las mismas causas: un token al portador robado y reutilizado en otra parte, un secreto de larga duración filtrado en un repositorio, una sesión que siguió viva mucho después de lo debido, justo lo que encontró el equipo de Sara el lunes. Token exchange, DPoP, SPIFFE y CAEP apuntan cada uno a uno de esos fallos.

Además, las identidades no humanas se han disparado. Cuentas de servicio, cargas de trabajo y ahora agentes de IA autónomos que actúan en nombre de las personas ya superan muchas veces en número a las identidades humanas, y cada una necesita autenticarse, tener un alcance acotado y poder revocarse como cualquier otra. Y en el lado humano, la regulación y la desconfianza hacia los intermediarios de datos empujan hacia modelos en los que la gente presenta pruebas en lugar de que un proveedor intermedie sus datos en cada transacción, que es lo que permiten las carteras y las credenciales verificables.

El problema de los microservicios

Una sola petición a una app moderna puede repartirse entre decenas de servicios: un API gateway llama al servicio de gastos, que llama a pagos, que llama a un libro contable. ¿Cómo sabe el servicio de pagos que la llamada viene de verdad de Sara, dentro de sus permisos, y no de un vecino confundido o comprometido? La respuesta ingenua, reenviar el access token original de Sara a todos los servicios, es justo el antipatrón. Ese token da mucho más de lo que necesita cualquier salto, y como es un token al portador, quien lo capture en cualquier punto de la cadena puede reutilizarlo en todas partes. Los estándares de la frontera atacan las dos mitades del problema.

Token exchange: mínimo privilegio en cada salto

El OAuth Token Exchange (RFC 8693) permite a un servicio cambiar el token que tiene por otro distinto: con menos alcance, dirigido al siguiente servicio y, si hace falta, con delegación (“el servicio A actúa en nombre de Sara”) o suplantación. Cada salto pide un token fabricado solo para el siguiente servicio y solo con el alcance que necesita.

sequenceDiagram
  accTitle: OAuth token exchange entre microservicios
  accDescr: Un usuario llama al servicio de gastos con un access token amplio. Antes de llamar al servicio de pagos, el servicio de gastos envía ese token al endpoint de token exchange del servidor de autorización y pide un token nuevo con alcance solo para pagos. El servidor de autorización devuelve un token reducido dirigido a pagos. El servicio de gastos llama entonces a pagos con ese token estrecho, de modo que cada servicio recibe solo el privilegio que necesita y un token capturado entre saltos solo vale para un destinatario.
  actor U as Usuario (Sara)
  participant O as Servicio de gastos
  participant AS as Servidor de autorización
  participant P as Servicio de pagos
  U->>O: Petición (token amplio del usuario)
  O->>AS: Token exchange: "un token solo para pagos"
  AS->>O: Token reducido (aud=pagos)
  O->>P: Llama a pagos (token estrecho)
  P->>O: Resultado

El resultado es mínimo privilegio en lo más profundo del sistema, no solo en la puerta de entrada. Un token capturado entre el servicio de gastos y el de pagos funciona en pagos y en ningún otro sitio, y la cadena de delegación queda explícita y auditable. Es el principio del ciclo JML, “solo el acceso que necesita la tarea”, llevado hasta una única llamada entre servicios.

El RFC 8693 distingue dos modos. En la delegación, el token nuevo deja constancia de que el servicio actúa en nombre de Sara, así que las dos identidades siguen visibles, que es la opción honesta y auditable por defecto. En la suplantación, el token simplemente se convierte en Sara, sin rastro del servicio intermedio. La delegación conserva la cadena de custodia y suele ser lo que quieres. La suplantación a veces es necesaria, pero borra quién hizo de verdad la llamada, así que úsala con moderación y registra mucho cuando lo hagas.

DPoP: que un token robado no sirva

El token exchange limita lo que puede hacer un token; DPoP (Demonstrating Proof-of-Possession, RFC 9449) limita quién puede usarlo. La debilidad básica de cualquier token al portador es que tenerlo basta. Lo robas y eres su dueño. DPoP ata el token a quien lo envía. El cliente genera un par de claves, el token queda vinculado a esa clave pública y, en cada petición, el cliente firma una pequeña prueba con la clave privada. El servidor solo acepta el token junto con una prueba válida, así que un token sacado de un log o de una llamada interceptada no sirve de nada sin la clave privada, que nunca salió del cliente legítimo. Si la app de gastos de Sara hubiera usado DPoP, el token del portátil robado seguiría funcionando, porque la clave también estaba en ese portátil, pero una copia filtrada en cualquier otro sitio no habría valido nada.

DPoP es el primo ligero del TLS mutuo que vimos entre los veteranos. Ata el token a su emisor en la capa de aplicación, sobre HTTPS normal, sin repartir un certificado a cada cliente. Es la respuesta a la advertencia del artículo de tokens de que los tokens al portador se pueden robar, y está pasando de ser vanguardia a ser lo esperado en las APIs de alto valor. Un token al portador es dinero en efectivo; DPoP es el chip y el PIN que hacen inútil una tarjeta robada.

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

El token exchange y DPoP protegen las llamadas; SPIFFE protege a quien llama. La pregunta de fondo en un mundo de microservicios es cómo tiene una carga de trabajo una identidad, para empezar. La respuesta antigua, meter un secreto compartido o una clave de API en cada servicio, produce un montón de credenciales de larga duración que nadie rota, como la clave de CI que encontró el equipo de Sara. SPIFFE (Secure Production Identity Framework for Everyone) lo sustituye por una identidad de carga de trabajo criptográfica. Cada servicio recibe un SPIFFE Verifiable Identity Document, un SVID, que es un certificado X.509 o un JWT con su nombre, emitido y rotado de forma automática por el entorno de ejecución, SPIRE.

En una service mesh como Istio, esta es la maquinaria que permite que cada llamada entre servicios vaya por TLS mutuo con las dos partes identificadas criptográficamente, sin que los desarrolladores gestionen un solo certificado. SPIFFE es, en la práctica, 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 que duran minutos y no años. Ahora que las identidades no humanas superan muchas veces a las personas, esta capa se está volviendo tan básica como el directorio humano. Dentro de poco, “¿quién puede acceder a esto?” se referirá a una carga de trabajo tan a menudo como a una persona.

Federación de identidad de cargas de trabajo

Un pariente cercano resuelve la versión entre nubes del mismo problema. La federación de identidad de cargas de trabajo permite que una carga de trabajo de un entorno se autentique en otro con una aserción de vida corta basada en OIDC sobre su propia identidad, en lugar de con un secreto guardado de larga duración. Un trabajo de CI/CD o una función en la nube A demuestra qué es y recibe una credencial temporal en la nube B, sin clave de API que filtrar ni secreto que rotar. Así sustituyó el equipo de Sara la clave de tres años: el trabajo de compilación presenta ahora un token del proveedor de identidad de la plataforma de CI y recibe credenciales que caducan en menos de una hora. Es el mismo instinto que SPIFFE, eliminar los secretos permanentes, aplicado entre fronteras de confianza, y se está convirtiendo deprisa en la forma por defecto de conectar sistemas en la nube.

Evaluación continua del acceso: cerrar el hueco de revocación

Volvamos a los cuarenta minutos. Como explicaba el artículo de tokens, un token autocontenido sigue siendo válido hasta que caduca, así que revocar el acceso a mitad de sesión es difícil. La respuesta de la frontera es evaluar el acceso de forma continua en lugar de decidirlo una sola vez al iniciar sesión. El Shared Signals Framework y su perfil 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 se ha revocado, este dispositivo ya no cumple, el riesgo de este usuario acaba de dispararse.

flowchart LR
  accTitle: Evaluación continua del acceso con señales compartidas
  accDescr: Un proveedor de identidad detecta un evento de seguridad, como una sesión revocada, un dispositivo que deja de cumplir o un aumento del nivel de riesgo de un usuario. A través del Shared Signals Framework envía en tiempo real una señal de evento de seguridad a cada aplicación suscrita. Cada aplicación recibe la señal y reevalúa o cierra al momento la sesión afectada, en lugar de seguir confiando en un token ya emitido hasta que caduque.
  EV[Evento de seguridad<br/>sesión revocada · riesgo del dispositivo · anomalía] --> IDP[Proveedor de identidad]
  IDP -->|envía señal| A1[App A reevalúa / cierra sesión]
  IDP -->|envía señal| A2[App B reevalúa / cierra sesión]
  IDP -->|envía señal| A3[App C reevalúa / cierra sesión]

El cambio es de concepto: el acceso deja de ser un hecho establecido al iniciar sesión y pasa a ser una suscripción en vivo que cualquiera de las partes puede actualizar. Cuando el servicio de ayuda desactivó la cuenta de Sara, una señal CAEP habría llegado a la API de gastos en segundos, y la sesión del portátil robado habría terminado ahí y no cuarenta minutos después. Es de esperar que se extienda allí donde “válido hasta que caduque” sea un valor por defecto demasiado peligroso.

Zero Trust como hilo conductor

Todas las tecnologías del lado de las máquinas son, en el fondo, formas de llevar a la práctica una idea: Zero Trust. El principio, recogido en NIST SP 800-207, es “nunca confíes, verifica siempre”: ninguna confianza implícita por estar en una red concreta, cada petición autenticada y autorizada, mínimo privilegio en todas partes y asumir que ya te han comprometido. El token exchange en cada salto es mínimo privilegio por petición y no por sesión. DPoP, mTLS y SPIFFE verifican a quien envía en lugar de fiarse de quien posee. CAEP vuelve a verificar de forma continua en lugar de fiarse para siempre de una decisión pasada. Las identidades de carga de trabajo de vida corta asumen que cualquier credencial puede estar comprometida y la hacen caducar pronto.

Zero Trust es la filosofía, que vimos en ciberseguridad centrada en la identidad; estos protocolos son la maquinaria que hace que “verificar siempre” salga lo bastante barato como para hacerlo a escala. Cuando alguien dice “estamos haciendo Zero Trust”, buena parte de esta pila es lo que debería querer decir. Si no, es un eslogan sin fontanería.

La otra frontera: credenciales verificables y carteras

Ahora, el lado humano. Hoy, cuando demuestras algo sobre ti, tu edad, tu título, tu colegiación profesional, sueles hacerlo 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) le dan la vuelta. Un emisor, como un gobierno, una universidad o una empresa, te entrega una credencial firmada y a prueba de manipulaciones. Tú la guardas en una cartera en tu dispositivo. Cuando un verificador necesita una prueba, se la presentas directamente, y el verificador comprueba la firma del emisor sin contactar con él. Tú, el titular, estás en medio y mantienes el control.

Dos piezas lo hacen funcionar. Una credencial verificable (modelo de datos VC del W3C) es la afirmación firmada en sí. Un identificador descentralizado, o DID (DID del W3C), es un identificador que controla el sujeto, anclado a un registro público o a un libro distribuido en lugar de emitido y poseído por un único proveedor, de modo que la firma del emisor se puede comprobar contra una clave que gobierna el titular y no un fabricante. Juntas hacen posible una identidad en manos del usuario: el titular decide qué presenta, a quién y cuándo.

Divulgación selectiva: demostrar menos

Una capacidad discretamente radical de este modelo es la divulgación selectiva, presentar solo el dato concreto que necesita el verificador y no la credencial entera. Con la criptografía adecuada, cada vez más con técnicas de conocimiento cero, un titular puede demostrar “soy mayor de 18” a partir de la credencial de su documento de identidad sin revelar su fecha de nacimiento, su nombre ni el número del documento. Compáralo con enseñar una foto del pasaporte, que lo expone todo. Revelar lo menos posible es la ganancia de privacidad que abre el modelo de cartera, y es una mejora real frente a las contraseñas y frente al inicio de sesión federado actual.

El problema abierto: revocar a escala

El triángulo de confianza tiene una pega que recuerda al problema de la revocación de tokens. Si el verificador comprueba una credencial sin contactar con el emisor, ¿cómo se revoca una credencial filtrada, caducada o retirada? La respuesta que se está imponiendo son las listas de estado, listas compactas publicadas, a menudo una cadena de bits, que el verificador consulta para saber si una credencial está revocada sin revelar cuál está comprobando. La revocación, la rotación de claves del emisor y la recuperación de la cartera, qué pasa cuando pierdes el móvil donde guardas tus credenciales, son los problemas poco vistosos que separan los pilotos actuales de la adopción masiva. Son el tipo de detalle que distingue una demo de un sistema desplegable.

OID4VCI y OID4VP: el puente desde OIDC

El riesgo de un paradigma de identidad nuevo es que lo reinvente todo y no conecte con nada. La comunidad de estándares lo evitó tendiendo un puente entre las credenciales verificables y el mundo OIDC que hemos visto en este módulo. OpenID for Verifiable Credential Issuance (OID4VCI) define cómo obtiene una cartera una credencial de un emisor, y OpenID for Verifiable Presentations (OID4VP) define cómo la presenta ante un verificador. Los dos funcionan sobre la maquinaria de OAuth y OIDC, los endpoints, los tokens y los flujos, así que el enorme ecosistema existente puede emitir y aceptar credenciales verificables sin empezar de cero. Ese pragmatismo es la razón de que el modelo de cartera tenga impulso real, sobre todo en la Cartera Europea de Identidad Digital bajo eIDAS 2.0 y en el permiso de conducir móvil ISO (mDL, ISO 18013-5).

Eso sí, descentralizado no significa el fin del directorio. Las empresas seguirán usando directorios, OIDC y SCIM durante mucho tiempo. Las credenciales verificables añaden un modelo nuevo junto a ellos, más fuerte allí donde una persona necesita demostrar algo entre organizaciones que no comparten directorio. Como siempre en identidad, la capa nueva se suma a la pila en lugar de sustituirla.

Expectativa y realidad

Una frontera atrae expectativas infladas, así que conviene tener clara la madurez. El token exchange, DPoP, SPIFFE y SPIRE, y la federación de identidad de cargas de trabajo están en producción a escala en organizaciones de ingeniería grandes; la frontera de las máquinas es real y llega deprisa. CAEP y Shared Signals ya han dejado atrás la teoría, con grandes proveedores ofreciéndolo, pero todavía no está en todas partes. Las credenciales verificables y las carteras maduran con mandatos públicos serios detrás, la cartera europea y los permisos de conducir móviles, pero la interoperabilidad, la revocación a escala y la usabilidad todavía se están resolviendo.

Así que la frontera de las cargas de trabajo es algo que conviene aprender ya porque lo usarás pronto, y la de las carteras es algo que conviene seguir de cerca porque está llegando. Ninguna está terminada, y justo eso las convierte en frontera.

Resumen

La frontera lleva el mínimo privilegio y el control del usuario más lejos de lo que llegaron los protocolos principales.

1. El token exchange (RFC 8693) estrecha los tokens y los redirige en cada salto, de modo que las llamadas entre microservicios llevan el mínimo privilegio en lugar de un único token con demasiado poder reenviado a todas partes.
2. DPoP (RFC 9449) ata los tokens a quien los envía, así que uno robado no sirve sin la clave privada del cliente: prueba de posesión ligera sobre HTTPS normal.
3. SPIFFE y SPIRE dan a las cargas de trabajo identidades criptográficas que rotan solas (SVID), un directorio y una PKI para máquinas que hace funcionar el TLS mutuo en la service mesh. La federación de identidad de cargas de trabajo extiende la idea entre nubes sin secretos permanentes.
4. CAEP y Shared Signals convierten el acceso en una suscripción en vivo, con eventos en tiempo real que permiten revocar sesiones a mitad de camino y cierran el hueco de revocación de los tokens sin estado.
5. Zero Trust es el hilo conductor: estos mecanismos son la forma de que “nunca confíes, verifica siempre” sea fontanería asequible y no un eslogan.
6. Las credenciales verificables y los DID ponen afirmaciones firmadas en la cartera de una persona, que las presenta a verificadores que confían en la firma del emisor sin llamarlo y con divulgación selectiva para proteger la privacidad. OID4VCI y OID4VP conectan ese modelo con OAuth y OIDC, y la capa nueva se suma a la pila en lugar de sustituirla.

Ejercicios prácticos

Están pensados para hacerse, no solo para leerse.

1. Sigue el mínimo privilegio. Una petición va del gateway al servicio de gastos, luego a pagos y luego al libro contable. Indica dónde meterías el token exchange y qué destinatario y alcance debería llevar el token de cada salto, y explica qué podría y qué no podría hacer un token robado entre gastos y pagos.
2. Justifica DPoP. Un equipo dice: “Usamos HTTPS, así que el robo de tokens no nos preocupa”. Explica qué hueco cierra DPoP que TLS no cierra, y cuándo lo exigirías en lugar de tokens al portador normales.
3. Diseña la identidad de las cargas de trabajo. Veinte microservicios se autentican entre sí con una clave de API compartida guardada en una variable de entorno. Describe cómo cambian las cosas con SPIFFE y SPIRE y nombra tres riesgos concretos que desaparecen.
4. Cierra el hueco de revocación. Una empleada deja la empresa y tiene que perder el acceso a diez apps SaaS de inmediato, pero todas usan JWT de 15 minutos. Explica cómo lo resuelven CAEP y Shared Signals y qué tiene que soportar cada app.
5. Recorre el triángulo. Con el triángulo de confianza, describe la emisión de una credencial “mayor de 18” y su presentación con divulgación selectiva en la web de control de edad de un local. Di quién firma, quién guarda y quién verifica, y qué sabe y qué no sabe exactamente el verificador.
6. Relaciónalo con Zero Trust. Toma un fallo real, la clave de CI en un fichero de configuración o el JWT todavía válido del portátil robado, y nombra la tecnología de la frontera que lo resuelve y el principio de Zero Trust que lleva a la práctica.

Tres preguntas para ponerte a prueba

1. Explica cómo el token exchange y DPoP atacan dos debilidades distintas de reenviar un token al portador por una cadena de microservicios.
2. ¿Por qué se dice que SPIFFE es un directorio para máquinas, y qué problema de los secretos compartidos resuelve la rotación automática de los SVID?
3. En el modelo de credenciales verificables, ¿cómo puede un verificador fiarse de una credencial sin contactar nunca con el emisor, y qué le permite al titular la divulgación selectiva no tener que revelar?