Las dos lecciones anteriores han dejado a Kilómetro Cero con tokens RS256 que todos los servicios verifican y con canales cifrados por los que viajan. Pero han dado por resuelto algo que no lo está: de dónde salen las identidades. servicios/identidad/tokens.py firma con una clave cuyo .pub se copió a mano a cada servicio; el login es un formulario propio con Argon2; los empleados de Kilómetro Cero tienen cuentas corporativas en otro sistema; los productores preferirían entrar con su cuenta de Google; la app de repartidores no debería mostrar nunca una contraseña de larga duración; y pedidos necesita un token de máquina para llamar a inventario cuando actúa por su cuenta (una saga de compensación de 03-05, por ejemplo) sin ningún usuario detrás. Resolver cada caso en cada servicio es inviable y, peor, inseguro: cada implementación propia de login es una oportunidad de error.

Esta lección centraliza la identidad en un proveedor de identidad (IdP) y explica los protocolos que permiten que una identidad establecida allí valga en toda la plataforma: LDAP como directorio de empleados, SAML 2.0 para el inicio de sesión único empresarial, y OAuth 2.0 con OpenID Connect para aplicaciones web, móviles y máquina-a-máquina. Veremos la federación con identidades sociales, el ciclo de vida de una identidad (alta, cambios de rol, baja), la autenticación multifactor y la recuperación de cuentas. Y lo pondremos en marcha: Keycloak como IdP en docker-compose.yml con un realm km0, tres clientes, roles y grupos por productor, y OpenLDAP para los empleados; un cliente OIDC en Python con PKCE, la obtención de un token de máquina para pedidos, y una búsqueda LDAP. La identidad de los servicios por certificado (mTLS) y la custodia de secretos son 06-04; el borde que valida todo esto de forma centralizada, 06-05.

1. Por qué centralizar la identidad
2. Proveedor de identidad frente a aplicaciones
3. Directorios LDAP: DIT, dn, ou, búsquedas y bind
4. SAML 2.0: inicio de sesión único empresarial
5. OAuth 2.0: delegación de acceso
6. OpenID Connect: identidad sobre OAuth 2.0
7. LDAP, SAML y OAuth2/OIDC comparados
8. Federación e identidades sociales
9. Ciclo de vida, MFA y recuperación
10. Kilómetro Cero: Keycloak como IdP y OpenLDAP para empleados
11. Código: cliente OIDC con PKCE, client credentials y búsqueda LDAP
12. Errores Comunes y Consejos
13. Ejercicios
14. Conclusión

Kilómetro Cero tiene cuatro poblaciones con necesidades distintas:

Si cada servicio gestiona sus usuarios, aparecen los problemas conocidos: contraseñas distintas en cada sitio (y reutilizadas), un empleado que deja la empresa sigue teniendo acceso a analitica porque nadie lo borró de allí, MFA en la web pero no en el panel de operadores, y cuatro implementaciones de recuperación de contraseña con cuatro conjuntos de errores. La centralización resuelve: una fuente de verdad de quién existe y qué atributos tiene, un punto donde aplicar MFA y políticas de contraseña, una baja que cierra todas las puertas, y aplicaciones que dejan de tocar credenciales.

El proveedor de identidad (IdP) es el sistema que autentica a los sujetos y emite pruebas de identidad (assertions SAML, tokens OIDC) que las aplicaciones consumen. Las aplicaciones pasan a ser partes confiantes (relying parties, o service providers en SAML): nunca ven la contraseña, solo la prueba firmada.

Keycloak, el IdP que usaremos, cubre todo el cuadro: base de usuarios propia, federación con LDAP y con proveedores sociales, emisión de tokens OIDC y assertions SAML, MFA, y una consola de administración. Alternativas con el mismo papel: Auth0/Okta, Azure AD (Entra ID), AWS Cognito, Ory, Authentik. Los protocolos son estándar; cambiar de IdP no debería cambiar el código de las aplicaciones.

LDAP (Lightweight Directory Access Protocol) es el protocolo de consulta de directorios: bases de datos jerárquicas optimizadas para lecturas, que almacenan personas, grupos, equipos y sus atributos. Active Directory de Microsoft es la implementación más extendida en empresas (con Kerberos para la autenticación en Windows); OpenLDAP y 389 Directory Server son las de código abierto. En Kilómetro Cero el directorio guarda a los empleados, que es lo que suele haber ya en cualquier empresa antes de que exista la plataforma.

El directorio es un árbol, el DIT (Directory Information Tree). Cada entrada tiene un DN (distinguished name) único, que es la ruta desde la raíz:

Conceptos:

• Entrada y atributos: cada nodo tiene atributos con tipos definidos por clases de objeto (inetOrgPerson aporta cn, sn, mail, uid; groupOfNames aporta member). El esquema es estricto: no se puede inventar un atributo sin declararlo.
• dn, ou, cn, uid, dc: distinguished name, organizational unit, common name, user id, domain component. El dn es la clave primaria; el resto son atributos con convenios.
• Búsqueda: se indica una base (ou=personas,dc=km0,dc=internal), un alcance (base, one, subtree) y un filtro con sintaxis de prefijo: (&(objectClass=inetOrgPerson)(memberOf=cn=operadores,ou=grupos,dc=km0,dc=internal)) devuelve los operadores; (|(mail=j*)(uid=j*)) los que empiezan por j.
• Bind: la autenticación LDAP. Un simple bind envía dn y contraseña; el servidor los verifica contra el hash almacenado (SSHA, o mejor, Argon2 en OpenLDAP moderno). Autenticar a un usuario "contra LDAP" es: (1) con la cuenta técnica, buscar el dn cuyo uid o mail coincide; (2) intentar un bind con ese dn y la contraseña que el usuario tecleó. Si el bind tiene éxito, la contraseña es correcta.
• LDAPS / StartTLS: LDAP en claro envía contraseñas en claro; siempre por TLS (puerto 636) o con StartTLS sobre el 389.

LDAP no es un protocolo de SSO: cada aplicación que autentica contra LDAP ve la contraseña del usuario. Por eso el papel de LDAP en una plataforma moderna es ser la fuente de usuarios y grupos que el IdP consulta, y no algo que las aplicaciones toquen directamente. Solo el IdP hace bind.

SAML (Security Assertion Markup Language, 2005) es el protocolo clásico de SSO entre empresas: un empleado entra una vez en el IdP corporativo y accede a decenas de aplicaciones de terceros (correo, nóminas, CRM) sin volver a autenticarse. Es XML firmado, transportado por redirecciones del navegador.

Actores y piezas:

• IdP: autentica y emite assertions: documentos XML firmados que afirman "el sujeto [email protected] se autenticó a las 10:02 con contraseña y MFA, y tiene estos atributos (grupos, departamento)".
• SP (service provider): la aplicación, que confía en el IdP porque tiene su certificado de firma, y que consume la assertion.
• Metadatos: cada parte publica un XML con sus URLs y certificados; se intercambian una vez al configurar la confianza.
• Bindings: cómo viaja el mensaje: HTTP-Redirect (en la URL), HTTP-POST (formulario autoenviado). Todo pasa por el navegador; IdP y SP no se hablan directamente.

El flujo SP-initiated (el usuario empieza en la aplicación):

El flujo IdP-initiated empieza en un portal del IdP con iconos de aplicaciones; es menos seguro (no hay InResponseTo que ate la respuesta a una petición) y se desaconseja salvo necesidad. SAML sigue siendo obligatorio cuando el IdP de un cliente corporativo solo habla SAML; para aplicaciones nuevas, OIDC es más simple y mejor adaptado a APIs y móviles. Keycloak habla ambos, así que el panel de operadores de Kilómetro Cero podría usar SAML si mañana se integra con un IdP corporativo externo, y OIDC hoy.

OAuth 2.0 (RFC 6749, 2012) nació para un problema distinto de la autenticación: delegar acceso. Ana quiere que una app de terceros lea sus pedidos de Kilómetro Cero sin darle su contraseña. OAuth define cómo esa app obtiene un token de acceso limitado (a ciertos scopes, durante cierto tiempo) con el consentimiento de Ana. Que después se use como base de la autenticación es obra de OpenID Connect (apartado 6).

Roles:

Los scopes son cadenas que acotan el permiso: pedidos:leer, pedidos:crear, reparto:posicion. El token lleva los scopes concedidos y el resource server los comprueba. Los tipos de cliente: confidencial (puede guardar un secreto: un servicio de backend) y público (no puede: una SPA en el navegador, una app móvil; cualquier secreto embebido es extraíble).

La razón de PKCE merece detenerse. En un móvil, el IdP devuelve el código a la app mediante una URL personalizada (km0://callback?code=...), y otra app maliciosa podría registrar el mismo esquema y capturarlo. Con PKCE, el código solo sirve junto al code_verifier original, que nunca salió de la app legítima. En una SPA, protege igual contra un código robado por un script o por los logs de un proxy.

OpenID Connect (OIDC, 2014) añade a OAuth 2.0 lo que le faltaba para autenticar: un ID token (un JWT, exactamente los de 06-01, firmado por el IdP) con claims sobre quién es el usuario y cómo se autenticó, un endpoint userinfo para obtener más atributos, y descubrimiento automático de la configuración.

• ID token: claims iss, sub, aud (= client_id), exp, iat, más auth_time, nonce (anti-repetición, generado por el cliente), amr (métodos: pwd, otp), y de perfil (email, name, preferred_username) según los scopes openid profile email. Va dirigido al cliente: le dice quién ha entrado.
• Access token: sigue siendo el de OAuth, dirigido a los resource servers (aud: [pedidos, inventario]). Keycloak lo emite también como JWT RS256 con los roles del realm, que es lo que AuthInterceptor de 06-01 verifica. No se debe usar el ID token para llamar a las APIs, ni el access token para saber quién está en la web.
• Discovery: GET https://identidad.km0/realms/km0/.well-known/openid-configuration devuelve un JSON con todos los endpoints (authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, end_session_endpoint) y los algoritmos soportados.
• JWKS (JSON Web Key Set): jwks_uri publica las claves públicas de firma del IdP, cada una con su kid. Esto sustituye al fichero .pub copiado a mano de 06-01: los servicios descargan las claves, las cachean, y cuando ven un kid desconocido las refrescan. La rotación de claves de firma pasa a ser automática.

El flujo completo con authorization code + PKCE, en Kilómetro Cero:

Fíjate en que web-km0 es un cliente confidencial (tiene backend y secreto) y aun así usa PKCE: no cuesta nada y OAuth 2.1 lo exige. app-repartidores es público y usa solo PKCE.

No compiten: el patrón habitual es LDAP detrás del IdP, SAML u OIDC delante, y OIDC para lo nuevo.

Federar es aceptar identidades de otro IdP. Keycloak actúa como broker: la Quesería Montblanc pulsa "Entrar con Google", Keycloak redirige a Google (que es a su vez un IdP OIDC), recibe el ID token de Google, lo verifica, y crea o enlaza una cuenta local en el realm km0 con sub propio. Las aplicaciones de Kilómetro Cero solo ven tokens de Keycloak: no saben ni les importa si el usuario entró con contraseña, con Google o con Apple.

Ventajas: menos contraseñas que gestionar, registro con un clic, MFA delegada en el proveedor social. Precauciones: el email no verificado de algunos proveedores no debe usarse para enlazar automáticamente con una cuenta existente (un atacante registra en el proveedor X un email ajeno y hereda la cuenta); Keycloak lo obliga a verificar. Y las cuentas de empleados nunca se federan con proveedores sociales: vienen del LDAP corporativo, con MFA obligatorio.

Una identidad no es un registro estático:

• Alta (onboarding): los clientes se autorregistran (con verificación de email); los productores son aprobados por un operador (rol productor y grupo del productor, apartado 10); los empleados aparecen en LDAP desde RR. HH. y Keycloak los sincroniza. SCIM (System for Cross-domain Identity Management) es el estándar REST para que un sistema de RR. HH. o un IdP cree, modifique y elimine usuarios en otras aplicaciones automáticamente; es lo que evita el "alguien tiene que darlo de alta a mano en cinco sitios".
• Cambios de rol: Marta pasa de atención al cliente a operaciones: cambia su grupo en LDAP, Keycloak lo refleja en la siguiente sincronización o en el siguiente login, y su próximo token lleva los roles nuevos. Con tokens de 15 minutos (06-01), la latencia máxima es esa.
• Baja (offboarding): desactivar en LDAP o en Keycloak, revocar sesiones y refresh tokens. Los access tokens vivos caducan en minutos. Es la razón por la que las bajas se hacen en el IdP y nunca aplicación por aplicación.
• Revisión periódica (access review): listar quién tiene operador y confirmar que sigue siendo cierto. Los permisos solo crecen si nadie los revisa.
• MFA: obligatoria para operadores y productores (TOTP con una app, o WebAuthn/passkeys); opcional pero fomentada para clientes. Se configura una vez en el IdP y aplica a todo. Keycloak la impone por flujo de autenticación y por rol.
• Recuperación: el punto más atacado. Enlace de un solo uso por email con caducidad corta, nunca preguntas de seguridad, verificación adicional para cuentas con MFA (códigos de respaldo), y registro de cada recuperación en la auditoría de 06-05. Un flujo de recuperación débil anula la mejor MFA.

Añadimos dos servicios a docker-compose.yml. Keycloak necesita su propia base de datos; OpenLDAP se inicializa con un LDIF con los empleados de ejemplo:

start-dev y --hostname=http://localhost:8080 son de desarrollo: en producción, Keycloak va detrás de TLS con start y un hostname real. El fichero identidad/empleados.ldif crea el árbol del apartado 3:

Y el realm, exportado a identidad/realm-km0.json (Keycloak lo importa al arrancar). Lo esencial, en forma de tabla porque el JSON completo ocupa cientos de líneas:

Con docker compose up -d keycloak openldap, la consola en http://localhost:8080 muestra el realm km0, y curl http://localhost:8080/realms/km0/.well-known/openid-configuration devuelve el documento de discovery. Jordi y Marta aparecen como usuarios federados desde LDAP, con el rol operador heredado del grupo; ninguna contraseña suya está en Keycloak.

El servicios/identidad/tokens.py de 06-01 queda retirado: Keycloak emite. Lo que sobrevive es servicios/comun/auth.py, con una única modificación: en lugar del .pub en fichero, usa el JWKS.

El AuthInterceptor de inventario y el decorador requiere_rol no cambian una línea: los tokens de Keycloak llevan roles y productor_id gracias a los mappers.

Este módulo es el que usa el backend de web-km0 (y, con las diferencias comentadas, la app de repartidores). Se implementa con requests para que se vea cada paso; authlib lo envuelve en tres llamadas y es lo que se usaría en producción.

Integrado en Flask, /login llama a iniciar_login, guarda pendiente en la sesión y redirige; /callback llama a completar_login, guarda sub, access_token y refresh_token en la sesión de servidor (Redis, 06-01) y redirige a la página. El navegador solo tiene la cookie HttpOnly de la sesión.

Comprobación rápida desde la terminal, con un usuario ana creado en el realm:

Cuando pedidos actúa por sí mismo (compensación de una saga, reconciliación nocturna), no hay token de usuario que reenviar. Pide el suyo:

El token resultante tiene sub: service-account-pedidos-servicio, roles: [svc-pedidos], aud: inventario. En ROLES_POR_METODO de inventario (06-01) se añade svc-pedidos a ReservarStock y LiberarReserva. Es la primera identidad de máquina real de la plataforma; 06-04 la reforzará con un certificado en lugar de un client_secret.

Los servicios no deberían hablar con LDAP (lo hace Keycloak), pero un operador sí necesita a veces consultar el directorio: por ejemplo, un script interno que lista quién está en operadores para la revisión de accesos del apartado 9.

Dos detalles de seguridad en el código: el filtro de búsqueda se construye con valores controlados (grupo viene de un argumento del script); si viniera de una entrada de usuario habría que escaparlo (ldap3.utils.conv.escape_filter_chars) para evitar inyección LDAP, el equivalente de la inyección SQL. Y la cuenta técnica es de solo lectura: si alguien roba solo-lectura, puede listar empleados pero no modificar grupos.

• Usar el ID token para llamar a las APIs (o el access token para identificar al usuario en la web). El ID token tiene aud: web-km0 y pedidos debe rechazarlo; el access token puede ser opaco en otros IdPs. Cada token para su destinatario.
• Omitir state o nonce "porque ya hay PKCE". Protegen contra ataques distintos: state contra CSRF en el callback (que te inicien sesión en la cuenta del atacante), nonce contra la reutilización de un ID token, PKCE contra la interceptación del código.
• redirect_uri con comodines. El IdP debe aceptar solo URIs exactas; un comodín permite que el código acabe en un dominio del atacante.
• Flujo password "porque es una app propia". Anula MFA, el consentimiento y la federación, y acostumbra al usuario a teclear su contraseña en apps. Authorization code + PKCE sirve también para apps nativas.
• Secretos de cliente en apps móviles o SPAs. Son públicos por definición; regístralos como públicos con PKCE.
• Aplicaciones que hacen bind contra LDAP directamente. Cada una ve contraseñas y ninguna aplica MFA. LDAP detrás del IdP.
• Enlazar cuentas sociales por email no verificado. Es la vía clásica de apropiación de cuentas.
• Bajas aplicación por aplicación. Una baja es desactivar en el IdP (o en LDAP) y revocar sesiones; si necesitas tocar cinco sistemas, el diseño está mal (SCIM existe para eso).
• Copiar el JWKS a mano o fijar una sola clave. El IdP rota claves; usa jwks_uri con caché y refresco por kid desconocido.
• Consejo: exporta el realm de Keycloak (kc.sh export) y versiónalo en identidad/realm-km0.json: la configuración de identidad es código, se revisa y se despliega igual que el resto.
• Consejo: prueba el flujo con un IdP real en desarrollo (Keycloak en Compose), no con un "modo sin autenticación". Las diferencias entre entornos en autenticación son la fuente clásica de sorpresas en producción.
• Advertencia de cumplimiento. Los datos de identidad (emails, nombres, grupos de empleados, proveedores sociales enlazados) son datos personales; su tratamiento, retención y la política de MFA y recuperación deben revisarse con un profesional de seguridad y protección de datos.

Un repartidor tiene instalada una app maliciosa que registra el esquema km0:// y captura la redirección km0://callback?code=XYZ&state=... antes que app-repartidores. Explica qué puede hacer la app maliciosa con ese código (a) si app-repartidores fuera un cliente confidencial con secreto embebido en el APK, (b) si fuera público sin PKCE, (c) con la configuración del apartado 10. Indica en cada caso qué comprobación de Keycloak falla o no falla.

Marta Puig (mpuig) deja Kilómetro Cero un viernes a las 17:00. Describe qué acciones realiza RR. HH./IT, en qué sistema, y qué ocurre con: su sesión abierta en el panel de operadores, su refresh token, un access token emitido a las 16:55, su cuenta en la wiki interna (que usa SAML contra Keycloak) y sus permisos en analitica. ¿Qué tendría que existir para que todo esto fuera una única acción? ¿Y qué falla si analitica mantuviera su propia tabla de usuarios?

km0_ventas_diarias (05-05) y el consumidor de Flink de pedidos.eventos (05-04) no tienen usuario. Diseña para cada uno: el cliente en el realm km0 (nombre, tipo, flujo, scopes/audiencia), los roles de servicio, cómo obtienen y renuevan el token, y qué comprobación añade inventario o el broker de Kafka. Señala qué parte de este diseño 06-04 va a cambiar y por qué.

Ejercicio 1.

(a) La app maliciosa extrae el secreto del APK (es trivial), canjea el código con client_id + client_secret y obtiene los tokens del repartidor: Keycloak no puede distinguirla de la app legítima; ninguna comprobación falla. (b) Sin PKCE, un cliente público canjea el código solo con client_id y redirect_uri; la app maliciosa lo hace antes que la legítima y obtiene los tokens; la legítima recibe un error al intentar canjear un código ya usado, que es la única señal, tardía. (c) Con PKCE S256 obligatorio, el canje exige el code_verifier cuyo SHA-256 se envió como code_challenge en la petición de autorización; la app maliciosa tiene el código pero no el verificador (nunca salió de app-repartidores); Keycloak calcula el hash del verificador que envíe (o rechaza su ausencia) y responde invalid_grant. El código queda inservible; la app legítima, si es la primera en canjear, entra con normalidad. state no interviene en este ataque (protege el callback contra CSRF, no contra interceptación).

Ejercicio 2.

IT desactiva uid=mpuig en OpenLDAP (o RR. HH. lo hace vía SCIM/sincronización desde su sistema). Keycloak, en modo READ_ONLY con sincronización periódica, ve la cuenta desactivada en el siguiente ciclo (o de inmediato si IT también la desactiva en Keycloak y revoca sus sesiones desde la consola, que es lo recomendable). La sesión del panel de operadores: si el panel guarda una sesión de servidor con el access token, sigue funcionando hasta que el token caduque (16:55 + 15 min = 17:10 como máximo) o hasta que intente refrescar; el refresh token fue revocado al cerrar sus sesiones en Keycloak, así que el refresh falla y el panel la expulsa. La wiki con SAML: la próxima vez que necesite reautenticarse (o de inmediato si la wiki recibe single logout), el IdP no la autentica; su sesión local en la wiki dura lo que dure su cookie, y por eso las sesiones de aplicaciones SAML se configuran cortas. analitica: si valida tokens de Keycloak, no hay nada que hacer allí. Para que todo sea una acción única hace falta que la baja se haga solo en la fuente (LDAP/RR. HH.) y que fluya por sincronización o SCIM hasta el IdP, con revocación automática de sesiones. Si analitica mantuviera su propia tabla de usuarios con contraseña, la baja no llegaría: Marta seguiría entrando en analitica el lunes, que es exactamente el motivo del apartado 1.

Ejercicio 3.

Airflow: cliente airflow-servicio, confidencial, solo service accounts (client credentials), scope/audiencia analitica y hdfs (si el lago se protege con tokens; en la práctica HDFS usa Kerberos, fuera del curso), rol de servicio svc-analitica-escritura; el DAG obtiene el token en un PythonOperator inicial (o un hook que lo cachee como token_de_servicio) y, como las tareas duran más de 15 minutos, lo renueva por client credentials cuando caduca (sin refresh token: client credentials se repite). Flink: cliente flink-pedidos-consumidor, confidencial, client credentials, audiencia kafka, rol svc-consumidor-pedidos; el broker de Kafka se configura con SASL_SSL y el mecanismo OAUTHBEARER, que valida el JWT contra el JWKS de Keycloak y aplica ACLs: ese principal solo puede leer pedidos.eventos con su grupo de consumidores, y no escribir en nada. inventario añade svc-analitica-... a los métodos de solo lectura si Airflow lo consulta. Lo que 06-04 cambia: el client_secret de ambos vive hoy en la configuración de Airflow y del job de Flink, es decir, en un fichero o variable de entorno; se sustituirá por autenticación con certificado de cliente (mTLS) o por un secreto inyectado y rotado por Vault, y las credenciales de PostgreSQL del DAG pasarán a ser dinámicas.

Centralizar la identidad significa que existe un único lugar donde se decide quién existe, cómo se autentica y qué atributos tiene, y que las aplicaciones consumen pruebas firmadas en lugar de contraseñas. LDAP es el directorio: un árbol de entradas con dn, unidades organizativas, grupos y bind, ideal como fuente de empleados detrás del IdP y pésimo como protocolo de login de aplicaciones. SAML 2.0 es el SSO empresarial por assertions XML, todavía necesario para integrar IdPs corporativos. OAuth 2.0 delega acceso con scopes y flujos, de los que solo tres importan hoy (authorization code con PKCE, client credentials y refresh), y OpenID Connect le añade la identidad: un ID token para la aplicación, un access token para las APIs, discovery para configurarse solo y JWKS para que la verificación RS256 de 06-01 rote claves sin intervención. La federación con identidades sociales, el ciclo de vida con SCIM, la MFA por rol y una recuperación cuidadosa completan el cuadro. Kilómetro Cero tiene ahora Keycloak con el realm km0, los clientes web-km0, app-repartidores y pedidos-servicio, roles y grupos por productor, OpenLDAP con Jordi y Marta, oidc_cliente.py con PKCE y validación contra JWKS, token_de_servicio() para pedidos, y una consulta LDAP para la revisión de accesos.

Y sin embargo, dos cosas siguen siendo frágiles. pedidos-servicio se identifica con un client_secret, que es una contraseña de máquina guardada en algún sitio; inventario acepta esa identidad porque el token es válido, pero no tiene forma de saber si la conexión TLS que le llega viene de verdad del contenedor de pedidos o de cualquier proceso que haya robado el secreto. Y la contraseña de km0_analitica sigue en una variable de entorno del DAG, como la dejó 05-05. La siguiente lección abandona la idea de perímetro: cada servicio tendrá su propio certificado, cada conexión se autenticará en ambos sentidos (mTLS), la autorización se hará también por identidad de servicio, y los secretos dejarán de escribirse en ficheros para vivir en Vault, con credenciales dinámicas que caducan solas.