How should my early stage B2B SaaS handle auth?
Pretty much all useful software needs to have auth. By this, I mean that software routinely needs to answer two general questions: first; who is this user; and second, what is this user allowed to do. There’s no way around it – you’ll need a way to handle auth.
I can't possibly tell you exactly how you should handle auth. I simply don't know enough about what you're working on. However, I may be able to help you get started with an evaluation.
Here’s my best effort at a guide to your options for auth for an early-stage B2B SaaS. I’ll do my best to keep things simple and brief.
Here’s roughly how I’ll approach things:
- What makes auth different from other product decisions you have to make?
- How do I know what my requirements are?
- How do I decide whether to build or buy?
- How do I evaluate my options for libraries and/or third-party services?
What makes auth different from other product decisions you have to make?
If you’re working on an early-stage SaaS, you make decisions about your product all the time. You’ll make tweaks to your UI, your onboarding flow, your pricing and packaging, and more. You’re constantly iterating, constantly polishing.
Auth looks a little different from the other parts of your product, though:
-
Your auth must be secure. In other parts of your product, you can make mistakes, but auth is the foundation of your security posture. If you make a mistake in your auth, you’re risking your customers’ data and your company’s reputation. The stakes are pretty high, and there are an awful lot of ways to get things wrong. To be clear, I’m not saying it’s beyond your ability – you just have to be very careful!
-
Your auth must be performant. You need to run auth checks pretty much every time your user takes meaningful action. Want to read from or write to the database? You need an authentication context. That means your auth needs to be reliable and fast. If auth goes down, your whole app goes down. If auth is slow, your whole app is slow.
-
Your auth just isn’t part of your core product. Jeff Bezos of Amazon has an aphorism that he likes: only do things that make your beer taste better. That is to say, a company should focus its efforts on the aspects of its products that customers really care about, the things that make the company uniquely great. I can pretty much guarantee that your auth isn’t going to make your SaaS uniquely great – no matter what you’re building. Customers will love the core features of your app; your login page isn't getting anyone excited.
In summary, you need your auth to be pretty close to perfect. It needs to work properly. But, paradoxically, you probably don’t want to spend too much time on it. You should do what you can to focus on your product.
How do I establish auth requirements for my SaaS?
Before you start building, you need to accumulate a set of requirements that will guide your thinking.
If nothing else, I want to drive home one idea: B2B auth is not like B2C auth! Even smart, experienced developers frequently get this wrong and regret it later. Please don't make this mistake!
Here are a few ideas to get you started.
B2B multitenancy
Business software uses a tenancy concept that isn’t relevant in consumer software: Organizations (alternatively called something like Workspaces). The general idea is that your customers are companies, and companies want control over their employees’ use of software.
You need to design logical isolation around a company-level concept. You can't just have Users. You need Users to belong to Organizations (or Workspaces, or whatever terminology you want to use).
Primary authentication factors
You should have some plan for the major authentication factors (i.e., ways of logging in) that you want to support. Here are a few of the major ones:
- Passwords
- Email (magic links)
- Social login over OAuth (e.g., Login with Google, Login with GitHub)
You’ll also need to make some decisions here. What happens if a user creates an account with a password and later tries to login using their Google Workspace account? Do you tie those accounts together? Do you keep them separate?
Secondary authentication factors
I know nobody enjoys it, but you really do need to have multi-factor authentication (MFA) set up.
If you're not familiar with MFA, just think of how you sign into your online banking account. In all likelihood, you enter a password first. Then, presumably, the bank text messages you a temporary code that you need to enter. In this scenario, you have proven your identity using two factors: a password and a short-lived code that proves you have access to a specific phone number.
Most people are pretty well-acquainted with using text messages as secondary auth factors, but this actually isn't a great solution. SMS is kind of insecure. That being said, it's better than nothing.
Here are the major secondary authentication factors you might want to support:
- One-time passcodes delivered via SMS (not ideal)
- One-time passcodes delivered via email
- 'Magic links delivered' via email
- Authenticator apps
- Passkeys
- Hardware tokens
Exactly which of these you need to support will probably depend on your customers. Having MFA in your app probably isn't something you'll need right away, but somebody will ask for it eventually.
Enterprise single sign-on
If you anticipate that you will ever sell your product into midsize or large companies, you will need to support enterprise single sign-on. Midsize or large companies generally want to control their employees' use of software applications by using software applications called identity providers (IDPs), such as Okta, Entra, or Sailpoint.
In nearly all cases, this means you need to support a protocol called SAML. SAML is very weird. It is very complicated. You have to be extremely careful with your SAML set-up. Even sophisticated companies like GitLab get SAML wrong.
If you want to know more about SAML, you can read my explainer here.
In some very rare cases, customers will want you to support enterprise single sign-on over a different protocol called OpenID Connect (OIDC). The good news is that OIDC is much simpler -- it's way harder to get it wrong. The bad news is that it's just another thing you need.
Programmatic provisioning
Remember how I mentioned that relatively big companies want to have single sign-on? How they don't want users to sign in directly to your application?
Companies will also want their identity providers (IDPs) to control the creation and deletion of users in your system. They'll ask you to support a protocol called SCIM. I wrote a simplified explainer of SCIM here if you want to learn more.
SCIM invites a surprising amount of complexity into your app. It's quite hard to do it correctly.
You will need your auth system to send emails to your users. For example, you'll probably want to support Forgot Password functionality. You'll want to do this over email.
That means you need a way to send transactional emails. Moreover, you need a way to send transactional emails that are fast and reliable. You can't have users waiting around for emails that never arrive. You can't have your emails in customers' spam folders.
When you do this, you'll also need a way to verify emails on account creation. This is extremely important.
You also need to decide whether emails are a unique identifier. Some people do this, but it can make life hard. (For example, what happens if a user changes their email alias?)
Authorization models
Not every use of business software is the same. Different people need to be able to do different things; your customers will not generally be very happy if every user has unbounded privileges!
You will need some kind of authorization model that distinguishes users' privileges within a tenancy boundary.
Most business software eventually uses an authorization design pattern called Role-based Access Control (RBAC, pronounced like ARR-back). The idea is that users have roles; users' permissions extend from their assigned roles.
For example, imagine you make some kind of email marketing software used by major apparel brands (e.g., Nike, LuluLemon, etc.). Since there are tons of people on the brands' mailing lists, the stakes are kind of high, and so the marketing leadership wants to make sure things pass through an approved process before going out. But there are a lot of people who work on these emails! So you might have a role called Draft collaborator that lets designers and marketers edit draft emails, but your might have a separate role called Email sender that restricts final sending to a small number of people.
Authorization can get extremely complicated. (RBAC is actually the simplest version of fine-grained authorization.) It's very likely that you won't need anything super involved, but it's essential that you have some intuition for your eventual authorization needs from the start.
User interfaces
You'll probably need more frontend code than you think. A login page isn't enough. Even if you're just using passwords, you'll need a page for resetting passwords when someone's authenticated, you'll need a page to kick off the forgot password flow.
Self-hosting, BYOC, and alternative clouds
You need to think a little bit about your deployment model. Do you need to support customers that want to run your software on their infrastructure? Do you have any customers that need Azure Governmment Cloud? Do you need to support Do you need to support folks with unique data residency obligations (e.g., we see this with many European customers).
In all likelihood, you don't need to deal with any of this in the short run. But we're seeing this stuff become relevant for startups much earlier than it did 5 to 10 years ago. You really don't want to be caught off guard.
Extra security features
You need to decide how much you want to protect your customers. (Ideally the answer is a lot, but I'll leave that much up to you!)
Expect that your users will opt for weak, re-used passwords. You will be vulnerable to credential stuffing and password spray attacks.
Expect that your users will fall for phishing schemes. You will likely want some kind of multi-factor authentication.
This is just more and more complexity.
Your options for auth
Build it all yourself
You can build auth yourself. If you're an experienced software developer, you can figure all of this out. Tons of people build auth themselves.
Mostly every web development framework has options for auth. Some are better than others. If you're on Rails, you can use Devise. If you're using Django, you'll have to wrangle its built-in auth, which is fine, but it's not the best. If you're writing Rust with Axum, you'll have to do a lot more work yourself (but you probably knew this going in).
Build on a low-level identity broker
You don't quite have to build everything yourself. You can build on some lower-level abstractions.
The most common open source option for this is Keycloak. It's certainly not easy to use, and it's a bit old-school, but I can promise you that it'll work.
You can also use some closed-source tools like AWS Cognito. Just to be blunt, I highly advise that you do not do this.
Build on a backend-as-a-service
You can use tools like Supabase or Firebase to handle your auth.
Such backend-as-a-service offerings are generally suitable for prototypes, but I haven't known any SaaS companies that have been happy to stick with their auth services in the long run. It's just hard for a company's secondary product to be best-in-class.
Just to make things a little concrete, we continually run into issues helping people layer SAML single sign-on over Firebase.
If you feel like this works for you, by all means -- go for it! Just be aware that you might feel compelled to make a change in the future.
Build on a closed-source auth service
There are lots of closed-source auth vendors. Here are a few:
Each of these vendors has its own quirks, but they're generally pretty capable.
They all present the same drawback, however. In return for convenience and abstraction, you forfeit some control over a core part of your infrastructure! You're locked in with a vendor.
Build on an open source auth service
You can blend the best of build vs. buy by using an open source auth service like Tesseral, which is built specifically for B2B SaaS. You can keep your maintenance obligations low and your performance high with the cloud service, but self-host whenever your requirements change.
Conclusions
Auth is hard -- not because it's beyond your ability, but because there's an awful lot of stuff you need to build. If you're going to build auth yourself, please be aware of what you're signing up for.
If you want to offload the burden to a vendor, you can use an open source service like Tesseral to retain control.
