Architecture Overview: Federating Identities at Scale

Federated identity stops being a diagram and starts being an operational problem the moment you have more than one application and more than one organization to serve. Each app wants its own login. Each organization wants its own users, its own rules, and its own boundary. Veripass exists to keep those boundaries intact while presenting a single, coherent control plane for identity.

This overview walks through how that control plane is built and why the multi-tenant model is the load-bearing decision.

One control plane, many tenants

At the center of Veripass is a multi-tenant organization model. Every organization is a first-class boundary: its members, policies, roles, and audit history live inside that tenant and never leak across it. Applications register against the platform and are then granted to specific organizations, so the same application can serve dozens of tenants without any of them seeing each other’s data.

This is what makes federation tractable at scale. Instead of standing up a separate identity stack per application or per customer, you operate one platform and express each customer as a tenant.

• Organizations are the isolation boundary — users, policies, and audit trails are scoped to them.
• Applications are registered once and federated into the organizations that need them.
• Identities can be local to Veripass or brought in from an external identity provider.

Federating external identity providers

Most enterprises do not want to move their users. They already run Microsoft Entra ID or Google Workspace, and they expect those to remain the source of truth. Veripass federates with both over OIDC, so a user authenticates against their home directory and Veripass consumes the resulting assertion to establish a session.

For provisioning, Veripass speaks SCIM, so accounts can be created, updated, and deprovisioned from the upstream directory rather than managed by hand. SAML and OIDC cover the inbound authentication surface; SCIM covers the lifecycle. Together they let an organization keep its existing directory as the system of record while Veripass handles cross-application federation, policy, and audit.

Machine-to-machine traffic is handled separately through API keys, so automated services and integrations authenticate without borrowing a human’s session.

Authorization is contextual, not just role-based

Federating who a user is only solves half the problem. The other half is deciding what they may do, and that decision has to account for context. Veripass models access through a layered scheme of claims, capabilities, roles, and access profiles, which lets you compose permissions rather than hard-code them per application.

On top of that sits context-aware, policy-based evaluation. Access can depend on the organization, the role, the application, and the conditions of the request — and when the risk rises, the platform can demand a step-up: adaptive MFA over email or phone TOTP, or biometric verification using face, ID document, or fingerprint.

Why it holds at scale

The architecture stays coherent because the hard boundaries are drawn once. Tenants isolate data. Federation keeps directories authoritative. Layered authorization keeps permissions composable. And every meaningful action lands in an immutable audit trail, so the same model that scales to many applications and many organizations also stays explainable to an auditor.

Whether Veripass runs in the cloud, on-premise, or in a hybrid topology, the federation model is the same — only the deployment surface changes.