Dentro do IDAM: O Motor de Identidade Por Trás da Xeni

Quando um passageiro reserva um hotel dentro de um superapp de transporte, quando um agente de uma agência anfitriã reserva uma viagem para um viajante, quando um agente de IA reserva um voo pela API, quando um microsserviço da Xeni chama outro — cada um desses momentos começa com a mesma pergunta: quem é você e o que você tem permissão para fazer?

Essa pergunta é respondida pelo IDAM, a camada de Identity & Access Management da Xeni. É a âncora de confiança da plataforma — o componente do qual humanos e máquinas dependem. Se o IDAM estiver indisponível, nenhuma conta consegue autenticar seus usuários e os serviços não conseguem provar quem os está chamando.

Esta publicação percorre o que o IDAM faz, por que ele foi projetado dessa forma e as capacidades que o tornam central ao stack de comércio de viagens da Xeni.

Um modelo de confiança, duas missões

O IDAM atende a duas audiências que nunca devem ser confundidas:

Confiança entre máquinas — para serviços

Cada microsserviço da Xeni depende do IDAM para validar uma solicitação recebida, emitir e verificar assinaturas HMAC (inclusive para widgets de reserva embutidos) e inspecionar um contexto de segurança criptografado. O resultado é uma postura de confiança zero: os serviços carregam um contexto de segurança assinado e criptografado em vez de compartilhar segredos de longa duração.

Autenticação humana — para pessoas

Viajantes, proprietários de contas e agentes de vendas se cadastram, fazem login, redefinem senhas, verificam códigos de uso único, usam login social ou se autenticam por um SSO configurado. Cada um desses fluxos está limitado a uma account — o inquilino que possui sua marca, domínio, cotas e políticas — que, por sua vez, fica sob uma organization principal.

Ambas as missões estão em produção hoje, e ambas são construídas sobre o mesmo motor de fluxos de trabalho Falcon e o mesmo modelo de confiança do contexto de segurança — convergindo para um único substrato de identidade. Duas audiências, uma única forma de estabelecer confiança.

Arquitetura em resumo

O IDAM fica entre dois tipos de chamadores e os planos de suporte da plataforma — dados, cache, segredos, jobs assíncronos e provedores de identidade externos.

Projetado para uma plataforma, não para um único app

A Xeni não é um app de viagens para consumidores — é uma infraestrutura de comércio de viagens, e seu modelo de identidade é moldado como uma plataforma em nuvem em vez de um produto único.

Organizações e contas

A entidade de nível superior é a organization — a mesma ideia de uma Organization da AWS ou GCP, onde uma empresa mantém muitas contas isoladas sob um mesmo teto. Sob uma org da Xeni, uma empresa cria quantas accounts tiver de negócios ou superfícies de integração, cada uma configurada por conta própria. Uma única empresa pode operar, sob uma organization:

• uma OTA account — uma vitrine de agência white-label;
• uma API account — uma integração direta que embute viagens em um superapp;
• uma MCP account — acesso programático para construir um agente de IA.

Uma organization, um proprietário, identidades mantidas claramente separadas por conta. Para o IDAM, cada account é um tenant: sua própria marca, domínio, provedores de identidade, cotas e políticas. Um novo negócio — uma coalizão de fidelidade, uma plataforma de gastos corporativos, outro agente de IA — é uma nova account na mesma superfície de identidade, não um fork do stack de autenticação.

Papéis são dados, não código

Proprietário de org, administrador de API, agente de viagens — estes são simplesmente roles. Um administrador de conta pode definir novos papéis e atribuir usuários a eles, de modo que o acesso se adapte a como cada cliente organiza suas equipes em vez de estar fixo na aplicação.

O acesso é granular

Permissões podem ser limitadas em três níveis, para que um cliente controle exatamente quem acessa o quê:

• Nível de funcionalidade — quais capacidades um papel pode usar;
• Nível de objeto — sobre quais registros específicos um usuário pode agir;
• Nível de atributo — quais campos dentro de um registro são visíveis ou editáveis.

Assim, um administrador de API em uma conta pode ter acesso programático amplo enquanto um agente convidado em outra vê apenas suas próprias reservas — até o campo. E como as regras de negócio rodam na borda do cadastro — Pricing, Subscription e Provisioning são chamados durante o registro — identidade, estrutura organizacional e limites comerciais permanecem alinhados à medida que cada conta é integrada.

Capacidades que importam no dia a dia

Por baixo dos panos, isso se traduz em cerca de duas dezenas de serviços de casos de uso focados — cadastro, login, logout, OTP, social, SSO, redefinição de senha, alteração de email e mais — cada um seguindo a mesma forma de pipeline para que novos fluxos permaneçam consistentes.

Para a plataforma

No lado das máquinas, o IDAM é a fonte de confiança:

• Validação de solicitações — transforma credenciais na borda (chaves de API, assinaturas HMAC, tokens de acesso, chaves de widget) em um contexto de segurança confiável.
• Introspecção — qualquer serviço pode pedir ao IDAM para descriptografar e verificar um contexto de segurança e retornar os claims, sem jamais possuir a chave privada.
• Geração de assinaturas — assinaturas HMAC com limite de tempo para clientes com chave de API e widgets embutidos.
• Resolução de versão — informa em qual versão do esquema de account um tenant está, para que migrações sejam incrementais.

Uma superfície de autenticação moderna, sem reescrever o núcleo

A autenticação humana cresceu historicamente como muitos endpoints orientados a verbos. O IDAM está consolidando-os atrás de uma superfície orientada a recursos — sessões, cadastros, redefinições de senha, desafios OTP e autoatendimento autenticado — despachados por um discriminador grant_type no corpo da solicitação.

Novas integrações obtêm um contrato mais limpo. Workers existentes permanecem intactos: despachadores finos traduzem a solicitação unificada nos handlers comprovados por fluxo, de modo que não há lógica de negócio duplicada e clientes podem migrar em paralelo com a superfície legacy.

Como as solicitações realmente são executadas

Cada handler é um pipeline de fluxo de trabalho Falcon:

No caminho de máquinas, a validação vai além — roteando por tipo de credencial, depois criptografando os claims, assinando-os e envolvendo-os em um envelope. A introspecção inverte essa cadeia.

O padrão traz três coisas que engenheiros valorizam: erros uniformes, observabilidade em nível de passo e um lugar previsível para adicionar uma nova capacidade — inserir um pacote de serviço, conectar uma rota.

Segurança como recurso de produto

Identidade sem criptografia são apenas formulários. O IDAM trata segurança como comportamento de produto de primeira classe:

• As senhas são hasheadas com bcrypt. As sessões são JWT com TTLs claros — vários dias para usuários autenticados, minutos para um contexto de segurança de máquina.
• A confiança entre serviços usa criptografia aninhada: claims são criptografados com AES-GCM, assinados com EdDSA e depois criptografados em envelope novamente. Serviços downstream fazem introspecção; nunca precisam da chave privada.
• As chaves ficam em um gerenciador de segredos gerenciado, versionadas por mês e rotacionadas por um fluxo de trabalho Temporal em intervalo configurável — com rotação e revogação disponíveis sob demanda, estendendo-se em direção a uma cadência por tenant. Material público pode ser cacheado amplamente; a chave privada de assinatura permanece na memória do processo e deliberadamente nunca é escrita no Redis.
• O Temporal também aquece os caches de chaves, para que caminhos quentes não esperem o gerenciador de segredos sob carga.
• Emails transacionais (verificação, redefinição, convite, OTP) são distribuídos de forma assíncrona via Kafka.

O resultado é um modelo de confiança que escala tanto em sessões humanas quanto na malha de serviços.

O que fica por baixo

O IDAM é intencionalmente estreito em escopo e profundo em responsabilidade: identidade e confiança, não reservas ou preços — mas fortemente integrado a esses sistemas onde decisões de identidade precisam de contexto comercial.

Por que este design se sustenta

Alguns princípios mantêm o IDAM durável à medida que a plataforma cresce:

1. 01Separar autenticação humana de confiança entre máquinas para que nenhuma audiência contamine a outra.
2. 02Fazer cada fluxo um pipeline para que o comportamento permaneça uniforme e observável.
3. 03Evoluir o contrato público sem reescrever workers — consolidar APIs por despacho, não por reescrita.
4. 04Suportar esquemas de account duplos para que migração de tenants possa ser gradual.
5. 05Automatizar o ciclo de vida das chaves para que rotação seja operacional, não heroica.

Essas escolhas são o motivo pelo qual um único substrato de identidade pode ser tanto o balcão de login para cada conta quanto o tecido de confiança para cada microsserviço.

Encerramento

O IDAM é fácil de resumir e difícil de substituir: é onde a Xeni decide quem alguém é, o que pode fazer e como todo outro serviço pode provar isso.

Se você está construindo um novo frontend voltado ao cliente, app mobile ou widget, comece na superfície consolidada de autenticação de usuário. Se você está construindo um novo serviço de plataforma, use validação, assinaturas e introspecção — e trate o contexto de segurança como o contrato, não segredos compartilhados.

Identidade é invisível quando funciona. Em uma plataforma de viagens multi-inquilino, essa invisibilidade é o produto.