By Pankaj Sharma
Last year, I was handed a problem that sounded simple on paper: let more partners plug into an authentication platform without weakening the trust model. In practice, this turned into one of the hardest architecture problems I’ve worked on, and it’s stuck with me enough that I want to walk through it here.
For context, the platform in question doesn’t just serve internal apps. It’s white-labeled out to partner companies — fintech apps, payment processors, insurance portals — who need their end users to log in using shared authentication rails. We started with a few hundred partners. The target was north of a thousand, eventually landing around 2,000+. Every one of them has a different risk profile, different data sensitivity, and different reasons to call the platform’s APIs.
The obvious question: how do you scale trust without scaling risk?
The problem with “one login flow for everyone”
Most authentication systems assume a fairly flat trust model. You log in, you get a token, the token proves who you are for a while. That’s fine when every consumer of the platform is equally trusted.
The moment you open that platform to external partners, flat trust breaks down fast. A partner running a low-risk, read-only integration and a partner initiating money movement shouldn’t be treated the same way, even if both are technically “authenticated.” Treating them the same either annoys the low-risk partner with unnecessary friction, or gives the high-risk partner more access than it should have.
Enter the Untrusted Partner Model
The approach we landed on treats every external partner as “untrusted by default” until proven otherwise for a specific action. Instead of authenticating once and calling it done, the system re-evaluates trust at checkpoints, based on what the user is actually trying to do.
Figure 1: Step-up authentication decision flow. Low-risk actions proceed with standard authentication; high-risk actions trigger an elevated check (OTP, biometric, or device trust signal) before a session token is granted. (Source: Author)
The step-up only kicks in when the action itself demands it. A partner checking account balances doesn’t trigger it. A partner initiating a transfer does. That kept friction proportional to risk instead of applying blanket rules everywhere.
Making it multi-tenant: config as the first API call
None of this holds together unless the platform actually knows which partner it’s talking to, and what that partner is allowed to do. With 2,000+ partners, hardcoding partner-specific logic anywhere in the codebase was a non-starter. We needed logical separation of behavior and data per partner, without maintaining 2,000+ separate deployments.
The pattern that worked was config-driven multi-tenancy, with configuration held centrally in Cassandra and resolved as the very first step of every API interaction, before any business logic runs.
Every incoming request carries four identifiers:
- Application ID – which partner application is calling
- Tenant ID – the logical tenant the request belongs to, allowing one partner to run multiple isolated business units if needed
- Channel ID – whether the request came from web or mobile, since risk posture and UX rules often differ by channel
- App Version – which version of the config contract the caller is built against
That last one matters more than it sounds. Config isn’t static — feature flags, risk thresholds, and step-up rules evolve over time. App Version lets us roll out changes without breaking partners who haven’t upgraded yet, and gives us a clean mechanism to sunset old behavior on a defined timeline instead of a hard cutover.
Figure 2: How every incoming request resolves its partner-specific configuration before hitting business logic. (Source: Author)
Cassandra made sense here mainly because of read patterns — this lookup happens on practically every call, so it needed to be fast, highly available, and tolerant of the platform growing partner by partner without redesigning the schema. Partitioning by Application ID and Tenant ID meant a partner’s configuration lookup never had to scan across unrelated tenants, which also helped keep data logically separated for compliance reasons, not just performance ones.
The nice side effect: onboarding a new partner became a config exercise, not a code change. A new tenant gets a config record; the same codebase behaves differently for them based on what that record says.
What I’d tell someone starting this today
If I were advising another architect walking into a similar problem, I’d say: don’t start with the authentication flow. Start with your partner classification model, and design your config schema around it early. The login flow and the step-up rules are both downstream of knowing who you’re trusting, why, and how that can change over time.
Second, centralize the decision, not the enforcement. Every downstream service still enforces its own checks, but they all ask the same config and policy layer “what applies to this request right now.” That single point of truth made audits far less painful and let the rules evolve without chasing down a hundred different implementations.
Scaling trust across a large partner ecosystem isn’t really an authentication problem. It’s a classification, configuration, and governance problem that happens to be implemented through authentication. Once that clicked, the rest of the architecture followed a lot more naturally.
Pankaj Sharma is a Lead Software Engineer (Solution Architect) with extensive expertise in technical leadership, system design, and platform engineering within the financial services space. Specializing in high-scale distributed systems, cloud-native application security (AppSec), and enterprise infrastructure automation, Pankaj has spent years building resilient backend architectures and secure-by-default pipelines for complex, domain-driven ecosystems. He is currently developing case studies on Post-Quantum Cryptography (PQC) migration patterns and practical implementation frameworks for Spring Boot platforms handling customer PII, payment processing, and regulatory document signing. Pankaj actively shares battle-tested engineering lessons and system design strategies through technical writing and architectural consulting.