Scaling Trust: How Calfus Unified Identity with OIDC Providers

At Calfus, we believe trust begins with identity. Today, organizations manage countless

dashboards, microservices, and user bases—making identity management a complex,

sprawling challenge. Especially when each client brings their own infrastructure and

compliance requirements to the table.

So how do you deliver secure, unified access at scale while giving each client full control of

their data and users? Here’s how we approached it at Calfus.

The Challenge: Fragmented Identity and Growing Pains Enterprises came to us with a common problem: they wanted seamless single sign-on (SSO) across dashboards and services. But the requirements varied:

• Strict boundaries for data and user access

• Preferences for enterprise IAM tools like Okta or open-source solutions

• A solution that could scale smoothly from startups to large enterprises

We noticed a repeating pattern among different customers—their authentication setups

varied, but their pain points were strikingly similar.

Our Approach: Combining Okta and Keycloak Our solution positioned Keycloak as both a standalone authentication service and a gateway to federate with other identity providers.

• Okta Integration: For enterprise clients, Okta delivers strong, enterprise-grade

authentication.

• Keycloak Multi-Tenancy: Each client operates within its own Keycloak realm,

ensuring complete isolation of data and policies.

• Federated Identity: Users authenticate via Okta, Microsoft Entra, PingID, or other

providers through a central Keycloak gateway.

• Tenant Routing Logic: The system routes users to their respective database schemas

based on JWT token data.

The result? A clean, scalable, and secure architecture offering flexibility without sacrificing

control. Implementation Highlights Subdomain-Based Routing

Every client is assigned a unique subdomain (e.g., customer.xyz.com). AWS Route 53

manages DNS, while the Application Load Balancer (ALB) secures traffic with certificates.

Dynamic Database Connections

Each JWT token includes a customer_id claim, which the backend uses to establish tenant-

specific database connection’s.This approach isolates tenant data and prevents cross-tenant access.

JWT Token Example

Pitfalls We Avoided • Single Realm for All Tenants: We opted for a realm-per-tenant design to enforce

strong isolation.

• Hardcoded Connections: Dynamic database connection logic leverages JWT claims

for flexibility.

• Complex Ingress Rules: Simplified, regex-powered configurations keep routing

clean and maintainable.

Production Deployment and Impact This architecture is live in production, successfully supporting multiple enterprise clients.

Key Outcomes

• Rapid onboarding of new tenants

• Real-time access visibility across dashboards

• Reduced complexity for client IAM integrations

• Scalability from 10 users to 10 million

Client feedback highlights the system’s simplicity and adaptability.

Looking Ahead

We’re exploring innovations like:

• Passwordless Authentication: Leveraging biometrics and passkeys

• AI-Driven Anomaly Detection: Real-time alerts for suspicious access patterns

• Event-Based Access Flows: Near real-time response to critical identity events Final Thoughts

Identity should empower, not restrict. Whether your user base is 10 or 10 million, a robust

multi-tenant identity strategy is vital.

If you’re navigating similar challenges, let’s connect. We’re always eager to share insights or

collaborate.