Foundations of scalable B2B auth

It’s easy to think about “authentication” as just an isolated, brief interaction where the user performs some sort of challenge to prove their identity. If you think about authentication in that way, your criteria for an authentication provider is probably something like “do they support X login method.” 

However, authentication is anything but isolated – it’s deeply coupled with your core assumptions about what defines a user. The foundational decisions you make around auth and user definitions have long-lasting impacts on how well you are able to scale to meet tomorrow’s needs.

Nowhere is that more true than in B2B. 

There are a few specific decisions that can make your later scaling journey either painless or challenging, so we’ll look at them one by one. 

1. Users and organizations

One of the very first decisions you need to make when building a B2B application is what defines a User, an Organization and their relationship. That sounds pretty easy at first glance – you’re building a tool for teams at work, so a User is an employee of an Organization.  Employees of the same company are all typically issued work email addresses, so a User is defined by their work email address. Right?

Kind of. 

The details around how you might implement this seemingly simple model can end up being the source of enormous headaches and end up limiting the use cases and enterprise customers you can sell to in the future.

Let’s take a look at each of those approaches and their implications. 

One to one relationship

One common approach is to say a User is defined by a globally unique email address and belongs to a single Organization. This makes a lot of intuitive sense – if your application is only something that people would use at work, then the most straightforward approach is to have them login and immediately land in the Organization context that they have access to.

However, this assumption will start to break down for any companies who work with contractors, agencies or external services that don’t receive corporate email addresses – or where a single company has multiple tenants within your application, in which a few individuals have access to multiple instances. 

If your data model and app architecture are based on the assumption that a user only has access to one Organization, users who need to have access to multiple Organizations will need to leverage email aliases to work around this constraint and will need to constantly be logging out and logging back in, just to switch Organization context. As you scale and start to hit these use cases, you are faced with a difficult choice between a time intensive migration of your core data model or continued frustration on the part of your users. 

One to many relationship

If you already know that there are use cases in which a single end user will have access to multiple Organizations, you might choose to say that a User is defined by a globally unique email address but can have permissions or membership to multiple Organizations.

It is particularly common to choose this data model in the interest of creating a seamless end user experience. After all, if we already know that this is ada.lovelace@stytch.com on Organization A, why would we add additional friction for the end user by asking them to re-authenticate when switching over to Organization B? Shouldn’t we just ask them to login once and then allow them to easily toggle between their different Organizations under the same session?

Unfortunately, if you achieve this low-friction experience by consolidating into a single User entity that spans multiple Organizations, that consolidation creates a lot of issues the minute you start trying to sell upmarket to enterprise companies. 

Most enterprises require the ability to set their own authentication policies for their members, and they have no reason to trust the authentication policies of other Organizations – particularly when it comes to authentication that happens through another company’s IdP. 

Therefore if ada.lovelace@stytch.com is a single UserID that belongs to both Organization A, which requires that their members all do password login with TOTP MFA, and Organization B, which requires that their members SSO via their workforce IdP, then she would need to go through both sets of authentication requirements – even if she just wants to access Organization A. This can become even more frustrating once you introduce configurable session durations, and Organization A requires that their users have to re-authenticate every 6 hours. 

The data model that seems low-friction for end users at small companies ends up creating tons of friction once you start selling to larger, more security aware customers.

2. JIT (Just-in-Time) provisioning 

If you allow self-onboarding (signing up for a new Organization via your site) you might have noticed that people frequently create a new Organization when really what they meant to do was join their co-workers in an existing Organization.

One really helpful way to address this issue is to introduce the concept of “JIT (Just-in-Time) Provisioning” by email domain. In this setup, an Organization can specify that users with a verified email address from a particular domain can automatically join their Organization without an explicit invite. 

This is incredibly helpful for smaller customers, who likely don’t have a dedicated IT admin in charge of provisioning employees to the tools that they need. Their team is small enough where they’re able to audit on an ad hoc basis.

That said, it can be easy to go overboard with JIT provisioning, and make decisions that haunt or hurt you – today or in the future. 

JIT and 1:1 user/org relationships

One common mistake we’ve seen that quickly becomes an issue is pairing JIT Provisioning with a 1:1 relationship between Users and Organizations. In this data model, an end user can only join a single Organization under their email address. 

This is fine, except if a new end user is accidentally JIT Provisioned to the wrong Organization, they are now prevented from joining the Organization they intended to or creating a new Organization without first deleting their account – which may require reaching out to customer support, creating a frustrating and friction-filled experience. 

This situation may seem unlikely, but consider the case where john.von.neumann@acme.com creates a new Organization on your application, turns on JIT Provisioning for all @acme.com email addresses – and then leaves Acme shortly after. As other Acme employees go to check out your app, they are JIT Provisioned to this abandoned Organization without an active owner – and since the 1:1 data model only allows a single email to belong to a single Organization, they must delete their accounts before being able to create a new Organization. This becomes even messier if your application automatically JIT Provisions, instead of asking the end user if they would like to join the application – because then there is no recourse without deleting the abandoned Organization itself.

JIT and SSO

JIT can also complicate matters further down the road when introducing SSO. Given that the main function of a workforce Identity Provider (IdP) is to centralize managing employee access to the company’s applications, it seems very natural to assume that you can automatically JIT provision any new user who successfully authenticates via the Organization’s IdP. 

However, this assumption starts to break down at scale, especially as you start to take on larger enterprise clients.  Some of the biggest Fortune 100 companies in the world use home-grown IdPs that don’t handle  app-specific provisioning – meaning that these companies will want to explicitly provision users to your application, rather than rely on their IdP as the source of truth on who can create an account.

It is important to always make JIT Provisioning configurable to account for the wide variety of company setups and preferences you’ll encounter at scale. As one tech lead we interviewed noted: “For every feature you introduce, someone will literally pay you for the ability to turn it off.” 

3. Simplicity doesn’t hold

Early on, all of the members of a given Organization share the same email domain and all use the same Identity Provider. Before you know it, these assumptions have been baked into the foundations of your application: your Organization object uses email_domain as the unique, primary identifier; you put the SAML IdP URI as a singular field on the Organization object; JIT Provisioning is a simple boolean; every member of the Organization shares the same sea

Until one day, you encounter your first prospect with subsidiary companies with different email domains, or different IdPs that all follow different JIT Provisioning rules, all within a single Organization.

Now you are tasked with the unpleasant reality of needing to take a massive refactor to remove uniqueness assumptions spread throughout your database models and millions of lines of application logic – right at the stage of growth when you have a million other, validated and differentiated projects you could be working on instead – or lose out on enterprise prospects whose basic authentication requirements are now “unsupported use cases”.

Save your team future headaches by making the right investments today

Speed of execution is one of the most critical factors in a company’s success or failure, and it is a very rational reaction to read this list of edge cases and say “that’s nice, but we can deal with that if we get there.” 

When you’re still iterating towards PMF, or if your target ICP today are other small startups, it would likely be a waste of precious time to build a fully extensible approach to auth that accounts for multinational subsidiaries, large scale acquisitions and homegrown IdPs. That’s years away, and you have pressing client needs now. 

However, once you’ve made some of these foundational decisions they become incredibly difficult and time consuming to unwind, crippling your ability to scale smoothly, and forcing you to shift resources away from much more differentiated and exciting parts of your product roadmap.

Luckily, you don’t actually need to make that tradeoff. Instead you can use an authentication provider that is built with these edge cases in mind, that can deliver the consumer-grade, conversion oriented authentication experiences that drive growth and align with your smaller customer’s authentication needs alongside the robust, enterprise grade requirements of the Fortune 100.