Dentro de IDAM: El Motor de Identidad Detrás de Xeni

Cuando un pasajero reserva un hotel dentro de una superapp de transporte, cuando un agente de una agencia anfitriona reserva un viaje para un viajero, cuando un agente de IA reserva un vuelo a través de la API, cuando un microservicio de Xeni llama a otro — cada uno de esos momentos comienza con la misma pregunta: ¿quién eres y qué tienes permitido hacer?

Esa pregunta la responde IDAM, la capa de Identity & Access Management de Xeni. Es el ancla de confianza de la plataforma — el componente del que dependen tanto humanos como máquinas. Si IDAM no está disponible, ninguna cuenta puede iniciar sesión para sus usuarios y los servicios no pueden demostrar quién los está llamando.

Esta publicación recorre qué hace IDAM, por qué está diseñado de esa manera y las capacidades que lo convierten en el centro del stack de comercio de viajes de Xeni.

Un modelo de confianza, dos misiones

IDAM atiende a dos audiencias que nunca deben confundirse:

Confianza entre máquinas — para servicios

Cada microservicio de Xeni depende de IDAM para validar una solicitud entrante, emitir y verificar firmas HMAC (incluso para widgets de reserva embebidos) e inspeccionar un contexto de seguridad cifrado. El resultado es una postura de confianza cero: los servicios llevan un contexto de seguridad firmado y cifrado en lugar de compartir secretos de larga duración.

Autenticación humana — para personas

Viajeros, propietarios de cuentas y agentes de ventas se registran, inician sesión, restablecen contraseñas, verifican códigos de un solo uso, usan inicio de sesión social o se autentican a través de un SSO configurado. Cada uno de esos flujos está acotado a una account — el inquilino que posee su marca, dominio, cuotas y políticas — que a su vez se encuentra bajo una organization principal.

Ambas misiones están en producción hoy, y ambas se construyen sobre el mismo motor de flujos de trabajo Falcon y el mismo modelo de confianza del contexto de seguridad — convergiendo en un único sustrato de identidad. Dos audiencias, una sola forma de establecer confianza.

Arquitectura de un vistazo

IDAM se sitúa entre dos tipos de llamadores y los planos de respaldo de la plataforma — datos, caché, secretos, trabajos asíncronos y proveedores de identidad externos.

Diseñado para una plataforma, no para una sola app

Xeni no es una app de viajes para consumidores — es una infraestructura de comercio de viajes, y su modelo de identidad está modelado como una plataforma en la nube en lugar de un producto único.

Organizaciones y cuentas

La entidad de nivel superior es la organization — la misma idea que una Organization de AWS o GCP, donde una empresa mantiene muchas cuentas aisladas bajo un mismo techo. Bajo una org de Xeni, una empresa crea tantas accounts como negocios o superficies de integración tenga, cada una configurada por su cuenta. Una sola empresa podría operar, bajo una organization:

• una OTA account — una tienda de agencia de marca blanca;
• una API account — una integración directa que embebe viajes en una superapp;
• una MCP account — acceso programático para construir un agente de IA.

Una organization, un propietario, identidades mantenidas limpiamente separadas por cuenta. Para IDAM, cada account es un tenant: su propia marca, dominio, proveedores de identidad, cuotas y políticas. Un nuevo negocio — una coalición de fidelidad, una plataforma de gasto corporativo, otro agente de IA — es una nueva account en la misma superficie de identidad, no un fork del stack de autenticación.

Los roles son datos, no código

Propietario de org, administrador de API, agente de viajes — estos son simplemente roles. Un administrador de cuenta puede definir nuevos roles y asignar usuarios a ellos, de modo que el acceso se adapte a cómo cada cliente organiza sus equipos en lugar de estar cableado en la aplicación.

El acceso es granular

Los permisos pueden acotarse en tres niveles, de modo que un cliente controle exactamente quién toca qué:

• Nivel de funcionalidad — qué capacidades puede usar un rol;
• Nivel de objeto — sobre qué registros específicos puede actuar un usuario;
• Nivel de atributo — qué campos dentro de un registro son visibles o editables.

Así, un administrador de API en una cuenta puede tener acceso programático amplio mientras que un agente invitado en otra ve solo sus propias reservas — hasta el campo. Y como las reglas de negocio se ejecutan en el borde del registro — Pricing, Subscription y Provisioning se invocan durante el registro — la identidad, la estructura organizacional y los límites comerciales permanecen alineados a medida que cada cuenta se incorpora.

Capacidades que importan en el día a día

Bajo el capó, eso se traduce en aproximadamente dos docenas de servicios de casos de uso enfocados — registro, inicio de sesión, cierre de sesión, OTP, social, SSO, restablecimiento de contraseña, cambio de email y más — cada uno siguiendo la misma forma de pipeline para que los nuevos flujos permanezcan consistentes.

Para la plataforma

En el lado de las máquinas, IDAM es la fuente de confianza:

• Validación de solicitudes — convierte credenciales en el borde (claves de API, firmas HMAC, tokens de acceso, claves de widget) en un contexto de seguridad confiable.
• Introspección — cualquier servicio puede pedirle a IDAM que descifre y verifique un contexto de seguridad y devuelva los claims, sin necesidad de tener la clave privada.
• Generación de firmas — firmas HMAC con límite de tiempo para clientes con clave de API y widgets embebidos.
• Resolución de versión — informa en qué versión del esquema de account se encuentra un tenant, para que las migraciones sean incrementales.

Una superficie de autenticación moderna, sin reescribir el núcleo

La autenticación humana creció históricamente como muchos endpoints orientados a verbos. IDAM los está consolidando detrás de una superficie orientada a recursos — sesiones, registros, restablecimientos de contraseña, desafíos OTP y autoservicio autenticado — despachados por un discriminador grant_type en el cuerpo de la solicitud.

Las nuevas integraciones obtienen un contrato más limpio. Los workers existentes permanecen intactos: despachadores delgados traducen la solicitud unificada en los handlers probados por flujo, de modo que no hay lógica de negocio duplicada y los clientes pueden migrar en paralelo con la superficie legacy.

Cómo se ejecutan realmente las solicitudes

Cada handler es un pipeline de flujo de trabajo Falcon:

En la ruta de máquinas, la validación va más allá — enrutando por tipo de credencial, luego cifrando los claims, firmándolos y envolviéndolos en un sobre. La introspección invierte esa cadena.

El patrón aporta tres cosas que les importan a los ingenieros: errores uniformes, observabilidad a nivel de paso y un lugar predecible para agregar una nueva capacidad — insertar un paquete de servicio, conectar una ruta.

Seguridad como característica de producto

La identidad sin criptografía son solo formularios. IDAM trata la seguridad como comportamiento de producto de primera clase:

• Las contraseñas se hashean con bcrypt. Las sesiones son JWT con TTL claros — varios días para usuarios autenticados, minutos para un contexto de seguridad de máquina.
• La confianza entre servicios usa criptografía anidada: los claims se cifran con AES-GCM, se firman con EdDSA y luego se vuelven a cifrar en sobre. Los servicios downstream hacen introspección; nunca necesitan la clave privada.
• Las claves viven en un gestor de secretos administrado, versionadas por mes y rotadas por un flujo de trabajo Temporal en un intervalo configurable — con rotación y revocación disponibles bajo demanda, extendiéndose hacia una cadencia por tenant. El material público puede cachearse ampliamente; la clave privada de firma permanece en memoria del proceso y deliberadamente nunca se escribe en Redis.
• Temporal también precalienta las cachés de claves, de modo que las rutas calientes no esperan al gestor de secretos bajo carga.
• Los emails transaccionales (verificación, restablecimiento, invitación, OTP) se distribuyen de forma asíncrona a través de Kafka.

El resultado es un modelo de confianza que escala tanto en sesiones humanas como en la malla de servicios.

Qué hay debajo

IDAM es intencionalmente estrecho en alcance y profundo en responsabilidad: identidad y confianza, no reservas ni precios — pero estrechamente integrado con esos sistemas donde las decisiones de identidad necesitan contexto comercial.

Por qué este diseño se mantiene

Algunos principios mantienen a IDAM duradero a medida que la plataforma crece:

1. 01Separar la autenticación humana de la confianza entre máquinas para que ninguna audiencia contamine a la otra.
2. 02Hacer que cada flujo sea un pipeline para que el comportamiento permanezca uniforme y observable.
3. 03Evolucionar el contrato público sin reescribir workers — consolidar APIs por despacho, no por reescritura.
4. 04Soportar esquemas de account duales para que la migración de tenants pueda ser gradual.
5. 05Automatizar el ciclo de vida de las claves para que la rotación sea operacional, no heroica.

Esas decisiones son la razón por la que un solo sustrato de identidad puede ser tanto el mostrador de inicio de sesión para cada cuenta como el tejido de confianza para cada microservicio.

Cierre

IDAM es fácil de resumir y difícil de reemplazar: es donde Xeni decide quién es alguien, qué puede hacer y cómo cada otro servicio puede demostrarlo.

Si estás construyendo un nuevo frontend orientado al cliente, app móvil o widget, comienza en la superficie consolidada de autenticación de usuario. Si estás construyendo un nuevo servicio de plataforma, apóyate en validación, firmas e introspección — y trata el contexto de seguridad como el contrato, no secretos compartidos.

La identidad es invisible cuando funciona. En una plataforma de viajes multi-inquilino, esa invisibilidad es el producto.