Why B2B Companies Waste More Time on Authentication

When you think about user authentication, where does your mind go to first? For most people, it’s a signup or login page, like this:

You can offer password login, passwordless/magic links, or a login with a social provider, like Google. You can also opt to collect more information on signup, such as the user’s name or where they found out about you.

What else do you need for a solid user authentication experience? Your users need some way to update their email address and password. For increased security, you can offer two-factor support (2FA), which means you’ll need a UI for your users to enroll and an extra step after login to verify it. You’ll need a profile or account page to manage all these settings.

There’s a deep rabbit hole to go down here about all the different ways you can setup and configure an authentication experience.

On top of everything we already mentioned, B2B companies have additional concerns to account for because they’re onboarding teams and other companies to sign up to their product, rather than individuals.

Organizations, Invitations, Roles, and Permissions

To understand some of the differences with B2B auth, let’s look at a product like Slack. You can use Slack by yourself, but it would be a little lonely.

That’s why one of the first things Slack asks you to do once you’ve signed up is invite your coworkers. This is usually the first step towards an authentication experience unique to B2B companies.

As we start to think through invitation flows, more concerns arise. For example, who has permission to invite people in the first place? Usually this is solved by adding roles (RBAC) and assigning each user a role with corresponding permissions. These roles are interesting because they are within the organization, meaning you might be the Admin of one organization and only have ReadOnly access to another.

You also need some way for your users to set the roles within their organization. With those roles, you can do authorization checks, like making sure only some people can access billing information within your product. These authorization checks would ideally exist in some re-usable auth middleware.

But, let’s say we solve all that. We add invitations, the ability to revoke invitations, a concept of organizations with its own management UI, roles, etc. We then get to meet the next fun challenge…

Enterprise SSO / SAML

Inviting each of your coworkers to a product is very reasonable when you are small, but what happens when you have 200 employees? Or 1000 employees? Those companies don’t want to spend all their time inviting new employees to each product that they are using. They especially don’t want manually remove every exiting employee from every single product they use, which, other than being very tedious, presents a real risk of forgetting to revoke access and having ex-employees retain permissions to your systems.

The solution here is to leverage the fact that most companies have some product they use to manage employees internally. This could be Google Workspace (previously GSuite), HR software like Rippling, or a product designed specifically for managing employees like JumpCloud and OneLogin. Whichever it is, these are called an Identity Provider (IDP).

In an ideal world, these companies could add an employee to their IDP and that employee would instantly get access to all the products they use at that company, such as Slack, Salesforce, and Notion. When an employee leaves, they’re removed from the IDP, revoking their access to those same products.

B2B products that want to sell to these larger organizations need to essentially access the employee data within their customers IDP to determine if they are an employee and get metadata about them. Luckily, there’s a standard protocol called SAML which allows products and companies to coordinate and have employees at the company sign in to the product with their company credentials.

The problem with SAML is that it’s not an opinionated protocol. Every IDP has some slight differences in how they implement it, even down to the names of the fields (is it an SP entity ID or an IDP entity ID? What’s the SSO URL.. is that the same as an ACS URL? Or Target URL?).

To make matters worse, to set up a SAML connection, both sides need to share information. The IDP provides some information to put into the product, and the product provides some information to put into an IDP. We’ve seen a lot of companies force customers to go through support to set up SAML connections and it’s a very tedious and error-prone process. This is why many people choose an auth provider to handle this for them.

At PropelAuth, we specifically designed step-by-step instructions to guide users through setting this connection, because we know how difficult it can be.

This also includes a SAML testing workflow, so your users can make sure the connection is working before they go live.

Summary

In the end, we’ve seen that while there are a lot of things to think about when approaching authentication in general, and, if you’re a B2B company, the concerns exponentially grow.

You start with an organization ID and an invitation flow, and slowly you are adding roles and self-service UIs, and org-aware middleware. And just when you are starting to close some larger customers, you get hit with the beast that is SAML.

We started PropelAuth because we understand that B2B startups don’t have the time, and often engineering resources, to build all this auth code themselves. We have first-hand experience trying to juggle building a product MVP only to spend more time getting working on auth. But our experience doesn’t have to be repeated, and you shouldn’t have to compromise your security or limit your ability to sell to enterprise customers.

Our goal is to take on as much of the burden as possible and just provide you with a user_id, org_id, and role for each user. We provide self-service UIs for everything from signup/login to organization management, including wizards that your users can use to setup SAML themselves, without any intervention from you. You can read more or test us out here.