Inside IDAM: The Identity Engine Behind Xeni

When a rider books a hotel inside a ride-hailing super-app, when an agent at a host agency books a trip for a traveler, when an AI agent reserves a flight through the API, when one Xeni microservice calls another — every one of those moments opens with the same question: who are you, and what are you allowed to do?

That question is answered by IDAM, Xeni's Identity & Access Management layer. It is the platform's trust anchor — the component both humans and machines depend on. If IDAM is unavailable, no account can sign its users in, and services cannot prove who is calling them.

This post walks through what IDAM does, why it is designed the way it is, and the capabilities that make it central to the Xeni travel-commerce stack.

One trust model, two missions

IDAM serves two audiences that must never be confused:

Machine trust — for services

Every Xeni microservice relies on IDAM to validate an incoming request, issue and verify HMAC signatures (including for embedded booking widgets), and introspect an encrypted security context. The result is a zero-trust posture: services carry a signed, encrypted security context rather than sharing long-lived secrets.

Human auth — for people

Travelers, account owners, and sales agents sign up, log in, reset passwords, verify one-time codes, use social login, or authenticate through a configured SSO. Every one of those flows is scoped to an account — the tenant that owns its brand, domain, quotas, and policies — which in turn sits under a parent organization.

Both missions run in production today, and both are built on the same Falcon workflow engine and the same security-context trust model — converging onto a single identity substrate. Two audiences, one way of establishing trust.

Architecture at a glance

IDAM sits between two kinds of callers and the platform's backing planes — data, cache, secrets, async jobs, and external identity providers.

Built for a platform, not a single app

Xeni is not one consumer travel app — it is a travel-commerce infrastructure, and its identity model is shaped like a cloud platform rather than a single product.

Organizations and accounts

The top-level entity is the organization — the same idea as an AWS or GCP Organization, where one company holds many isolated accounts under a single roof. Under one Xeni org, a company creates as many accounts as it has businesses or integration surfaces, each configured on its own. A single company might run, under one organization:

• an OTA account — a white-label agency storefront;
• an API account — a direct integration embedding travel into a super-app;
• an MCP account — programmatic access for building an AI agent.

One organization, one owner, identities kept cleanly separate per account. To IDAM, each account is a tenant: its own branding, domain, identity providers, quotas, and policies. A new business — a loyalty coalition, a corporate-spend platform, another AI agent — is a new account on the same identity surface, not a fork of the auth stack.

Roles are data, not code

Org owner, API admin, travel agent — these are just roles. An account admin can define new roles and assign users to them, so access adapts to how each customer organizes its teams instead of being hard-wired into the application.

Access is fine-grained

Permissions can be scoped at three levels, so a customer controls exactly who touches what:

• Feature level — which capabilities a role can use;
• Object level — which specific records a user can act on;
• Attribute level — which fields within a record are visible or editable.

So an API admin on one account can hold broad programmatic access while an invited agent on another sees only their own bookings — down to the field. And because business rules run at the edge of signup — Pricing, Subscription, and Provisioning are called during registration — identity, org structure, and commercial limits stay aligned as every account onboards.

Capabilities that matter day to day

Under the hood, that maps to roughly two dozen focused use-case services — signup, login, logout, OTP, social, SSO, password reset, email change, and more — each following the same pipeline shape so new flows stay consistent.

For the platform

On the machine side, IDAM is the source of trust:

• Request validation — turns credentials at the edge (API keys, HMAC signatures, access tokens, widget keys) into a trusted security context.
• Introspection — any service can ask IDAM to decrypt and verify a security context and return the claims, without ever holding the private key itself.
• Signature generation — time-bounded HMAC signatures for API-key clients and embedded widgets.
• Version resolution — reports which account-schema version a tenant is on, so migrations stay incremental.

A modern auth surface, without rewriting the core

Human auth historically grew as many verb-oriented endpoints. IDAM is consolidating them behind a resource-oriented surface — sessions, registrations, password resets, OTP challenges, and authenticated self-service — dispatched by a grant_type discriminator in the request body.

New integrations get a cleaner contract. Existing workers stay untouched: thin dispatchers translate the unified request into the proven per-flow handlers, so there is no duplicated business logic and clients can migrate side by side with the legacy surface.

How requests actually run

Every handler is a Falcon workflow pipeline:

On the machine path, validation goes further — routing by credential type, then encrypting the claims, signing them, and wrapping them in an envelope. Introspection reverses that chain.

The pattern buys three things engineers care about: uniform errors, step-level observability, and a predictable place to add a new capability — drop in a service package, wire one route.

Security as a product feature

Identity without cryptography is just forms. IDAM treats security as first-class product behavior:

• Passwords are bcrypt-hashed. Sessions are JWTs with clear TTLs — multi-day for authenticated users, minutes for a machine security context.
• Service-to-service trust uses nested cryptography: claims are AES-GCM encrypted, EdDSA signed, then envelope-encrypted again. Downstream services introspect; they never need the private key.
• Keys live in a managed secret manager, versioned by month and rotated by a Temporal workflow on a configurable interval — with rotation and revocation available on demand, extending toward per-tenant cadence. Public material can be cached broadly; the signing private key stays in process memory and is deliberately never written to Redis.
• Temporal also warms the key caches, so hot paths do not wait on the secret manager under load.
• Transactional emails (verification, reset, invite, OTP) fan out asynchronously over Kafka.

The result is a trust model that scales across both human sessions and the service mesh.

What sits underneath

IDAM is intentionally narrow in scope and deep in responsibility: identity and trust, not booking or pricing — but tightly integrated with those systems where identity decisions need commercial context.

Why this design holds up

A few principles keep IDAM durable as the platform grows:

1. 01Separate human auth from machine trust so neither audience pollutes the other.
2. 02Make every flow a pipeline so behavior stays uniform and observable.
3. 03Evolve the public contract without rewriting workers — consolidate APIs by dispatch, not by rewrite.
4. 04Support dual account schemas so tenant migration can be gradual.
5. 05Automate the key lifecycle so rotation is operational, not heroic.

Those choices are why one identity substrate can be both the login desk for every account and the trust fabric for every microservice.

Closing

IDAM is easy to summarize and hard to replace: it is where Xeni decides who someone is, what they can do, and how every other service can prove it.

If you are building a new customer-facing frontend, mobile app, or widget, start on the consolidated user-auth surface. If you are building a new platform service, lean on validation, signatures, and introspection — and treat the security context as the contract, not shared secrets.

Identity is invisible when it works. On a multi-tenant travel platform, that invisibility is the product.