Designing B2B Authentication Experiences: Universal vs. Organization-Specific Login

One of the first decisions you must make when architecting a new B2B application? How you’re going to allow users to authenticate.

You have two choices: the universal login page or the organization-specific login page. We’ll make the distinction clear in a moment, but for now, know that the path you choose here has significant downstream effects on the entire lifecycle of your B2B application, and in ways far more significant than designing and developing a login page that looks good. Notably, three personas are most affected with the choice you make:

• Your internal product engineers, who build your application.
• Your customers’ IT administrators, who provision users, manage privileges, and enable single sign-on (SSO) integration with their identity providers (IdPs) such as Okta, Microsoft Azure AD.
• Your product’s users, who will be logging into your application.

Conveniently, two popular applications—Notion and Slack—have made opposite choices for end-user authentication flows. Their ubiquity makes them ideal for identifying how they implemented differing flows, tracing the pros and cons for each affected persona, and ultimately helping you create the best authentication paradigm for your application.

What are the Notion and Slack styles of Authentication?

Before diving too deeply into authentication nuances, let’s clarify our definitions.

• Notion-style authentication flow uses universal login page
• Slack-style authentication flow uses organization-specific login page

How are they different?

With a universal login page, the application identifies which organization the end user belongs to. In contrast, with an organization-specific page, the end user shares the organization as input to the application before they can be authenticated.

With Notion, you start authentication by loading the universal login page at notion.so/login. You give your work email address, which Notion uses to identify which organization you belong to based on the domain name. If your email is celina@foocorp.com, Notion assumes you’re part of the organization associated with foocorp.com.

Notion uses that information to provide you with the next best step for the authentication flow, which might be entering a password, using SSO, receiving a magic link, or any auth setting configured by your IT admin.

In the case of Slack’s authentication experience, as an end user, you must navigate to the Slack’s organization-specific login page at a specific URL, like foocorp.slack.com. In this case, you’ve already specified which organization you belong to (Foocorp) through the subdomain, and Slack uses that information to show you the appropriate authentication flow.

In both cases, once the application identifies the end-user’s organization, it honors their authentication settings, including SSO, identity provider, multi-factor authentication (MFA), password policy, and so on.

The user experience (UX) around honoring those settings can still vary between applications. Notion’s universal login page, for example, separates the email and password fields so it can perform the home realm discovery (that’s discovering the tenant) and honor auth settings.

Note that, Dropbox hides the password field if the email address entered matches a tenant with enterprise authentication enabled.

Freshworks takes yet another approach, using home realm discovery to ascertain your tenant and redirecting your browser to an organization-specific login page.

Again, these differences might seem small, but the impact is outsized by a few orders of magnitude by the resulting choices around implementation and infrastructure.

Contributing technical factors: tenancy and home realm discovery

Tenancy is the architectural decision to isolate the authentication policies, settings, users, and data between each organization registered with an application. Multi-tenant architecture is an essential ingredient for the authentication and security of a SaaS app, ensuring a user of organization Foorcorp can never read data belonging to organization Barcorp.

Home realm discovery (HRD) is the process by which a application identifies which tenant a user belongs to from the login page. Because every application uses a multi-tenant architecture, HRD is also necessary, as there could be a hundred Celina users, each belonging to a different organization and stored inside a different tenant. HRD requires an identifier, which applications collect in a few standard ways:

• The domain name (foocorp.com) on the end-user’s work email.
• An organization-specific “username,” like Foocorp.
• A user-specific ID that cannot be repeated elsewhere, like celina0001 versus celina0002.

If we map this idea to the universal and organization-specific login pages concept from before, we can clarify our definitions even more.

• With a universal login page, the application must complete some type of HRD to authenticate end users.
• With an organization-specific login page, the HRD is done as the user inputs the organization name as part of the authentication process.

Once the application completes HRD and maps the end user’s identifier to a tenant, it can honor those authentication settings and allow them to finish logging in using approved methods. Now that you understand the two possible authentication flows for a application, and how each works alongside your required multi-tenant architecture, we can explore those big implications.

For your app’s internal engineering team

Universal Login

• Pros
  • Universal login pages are easy to design and develop, as only one possible user interface (UI) and common UX pattern exists.
  • You can extend universal login pages to allow a single user to log in to multiple workspaces for cross-organization collaboration similar to Notion.
• Cons
  • Your team must implement a robust Home Realm Discovery (HRD) to discover the appropriate tenant that a user belongs to based on the user input. This Home Realm Discovery can either based on user’s email address of explicit input of user’s tenant information like Account Name, Organization ID etc. This requires additional engineering effort for the HRD implementation.
  • If your customers require data residency, you must engineer more network-level workarounds to redirect users to the appropriate tenant and region.

Organization-specific Login

• Pros
  • Users perform HRD on your behalf by supplying the subdomain, which simplifies your backend logic.
  • In some ways, it’s easier for your team to manage data residency, as you can map the DNS records for a specific tenant (foocorp.com) to cloud resources in their region of choice.
• Cons
  • Instead of designing and developing a single authentication flow, your team is now responsible for many.
  • Must develop additional measures to help new users remember the URL for their login page, such as email reminders. You may even want to create a method for them to recover a “lost” organization.

For your customer’s IT administrator

Universal login

• Pros
  • Similar to the development process, they only have a single authentication flow and login page to worry about.
• Cons
  • IT administrators at enterprise organizations might require far more customization than a universal login page can offer.

Organization-specific login

• Pros
  • Customize the login page so their users perceive the product as a white-labeled solution.
  • Restrict authentication methods to only an approved subset of the available options, simplifying the UX and moving users toward the “best” option.
  • Add custom terms or disclaimer notices onto the login page for legal or compliance purposes.
• Cons
  • Must educate their employees or customers to visit the specific URL to access the application.

For your application’s end user

Universal login

• Pros
  • The UX is extremely straightforward: they navigate to a well-known URL like notion.so/login or through a big Log in button on your homepage.
• Cons
  • None.

Organization-specific login

• Pros
  • The UX around approved authentication methods
• Cons
  • End users must remember the URL for their organization-specific login page. If they can’t remember or retrieve the information, they could be frustrated enough to create a new account or abandon your application altogether.

How do you choose between a universal vs. organization-specific login page?

Frankly, there is no direct answer. The best solution is based on your customers and admins experience in your application. As you’re making other architectural and technical decisions, such as which JavaScript UI framework to choose, whether to build a monolith or many microservices, or which cloud provider gives you the most startup credits, you should take time to weigh the user experience for each persona in light of your long-term go-to-market (GTM) strategy.

Generally, if you’re appealing to the end-user experience, universal login pages are most familiar to the widest range of users. If you need to offer the customer IT administrator complete flexibility, or are selling to enterprise customers who expect a completely white-labeled solution, then organization-specific pages are a great fit.

What type of login page did Scalekit pick? When we reach general availability, we’ll use a universal login page, where our application performs HRD using the user’s work email as the identifier.

We opted for the universal login page to ensure our users always have the simplest possible experience logging in. We don’t want situations where users have lost their accounts simply because they forgot which subdomain they’re supposed to navigate to. We know that comes at a higher technical cost to us around HRD, but it’s a sacrifice we’re willing to make for the most seamless end-user experience.

The other decision you must make early on is how you’ll build the authentication integration itself. You can go it alone and build a SAML implementation for ultimate control at the cost of complexity and many developer hours, or you can partner with a platform like Scalekit to get your B2B application enterprise-ready in days, not weeks or months.

Either way, ensure your choice lets you also pick the login page that works best for your customers—once you’ve started developing and deploying infrastructure, you can’t take your choice back.