[mooreds]

Disclosure: I work for an auth service vendor.

Great feedback about knowing who the buyer is. Lots of folks think about the user, but knowing the buyer (and they are usually not the same person) is critical too.

If you are a building a SaaS, I'd recommend outsourcing your auth, since that is both critical and undifferentiated functionality.

There are lots of solutions out there. FusionAuth is one option (I work there); here's our multi-tenant guide: https://fusionauth.io/docs/v1/tech/guides/multi-tenant .

There are of course other options too. Here are some I've heard of that seem like they fit your needs (offering some combination of RBAC, SSO, and multi-tenancy), but I'd suggest doing a spike:

* clerk.dev

* workos

* supertokens

* propelauth

You could also start off with an open source solution like devise/omniauth (if building on rails) or passport.js (if building on JS). I'd only go down this path if you are familiar with the tech, as it can be difficult to configure if it is your first time, and, again, this is critical but undifferentiated functionality.

[pclmulqdq]

I'm not entirely sure I agree with this - most auth providers are very expensive, and if you don't need the full-featured offering, you are way overpaying for the engineering time to build your replacement.

If you need all the features, it's a good deal, but you rarely do unless you are building something like Notion or Jira.

Open source components (Ory) can do the basic cryptography, and if you go completely from scratch, the NIST and their European counterparts have well-written standards for how to do this, and if you follow the relevant parts of the standard, you will get something essentially perfect without the baggage.

[mooreds]

> most auth providers are very expensive

Some are, sure, but there are many that are not.

FusionAuth (again, I'm an employee) has a free community edition ( https://fusionauth.io/pricing?step=plan&hosting=self-hosting ) if you run it yourself with no limits on MAUs, SAML connections, tenants or users. Of course, we have plans that cost money because, hey, we all like to eat.

Auth0 has a basic plan that is free for 7k users. Mostly focuses on username and password, but is entirely adequate for getting started.

Ory (suggested elsewhere in the thread and by you) is OSS and free. Again, you have to operate it, which isn't free, but you get the benefits of upgrades and a team focused on auth.

Keycloak has a lot of features and is free if your run it yourself.

Supertokens has a basic plan that is free for 5k users.

There are many more, as well. And that is to say nothing of the OSS libraries (like devise/omniauth) which you can leverage.

Coding this from scratch seems like an enormous waste of time for something that is not typically a differentiator. At the least, use an OSS library or auth service and limit yourself to the features you need.

Customers pay for features, not for auth. Auth is just the front door to the application.

[pclmulqdq]

I think you're assuming that scratch coding is slower than integrating an OSS you don't know. When I was thinking about this for one project, it came close enough that I rolled my own basic auth system according to the NIST recommendations and it definitely took less time than integrating something that I didn't know (and accepting all the unknown bugs that are inevitably there).

I also don't buy the argument "don't waste time on something that is not a differentiator" - I'm going to spend time on it anyway, so I might as well spend the time in the most productive way possible. Also, I guarantee that your solution isn't bug-free, and eventually one of them is going to bite me, so that also factors into the decision about time.

The basic version of authentication is actually really simple. When you add SSO, RBAC, Oauth2, ACLs, and other stuff, it gets really complicated. People should make intelligent decisions about what they want to do here rather than just using a provider.

[mooreds]

> I think you're assuming that scratch coding is slower than integrating an OSS you don't know.

I think that depends on all kinds of factors (domain knowledge, docs of the library, etc). I think learning one or two auth libraries or frameworks will be useful to most devs, as they can re-use that knowledge repeatedly. But I get your point, sometimes rolling your own can be quicker. (And it is certainly more fun to code something up than to read up on integration docs.)

However, I think you're dismissing the long term maintainability advantages you get from using a focused library or auth server.

When a request comes in for a feature (let's change the hashing algorithm and factor of our passwords to meet new NIST standards, let's add login with LinkedIn, can we integrate using SAML), if you have the right library or auth server, it's often a configuration parameter, as opposed to code.

When there's a security issue, someone clearly owns it and has an incentive to fix it as fast as possible. Some auth servers (FusionAuth among them) pay people regularly to penetration test the system. Is that something you are going to do with your homegrown auth system?

That said, I'm glad you found a solution that works for you. Different strokes for different folks, as they say.

[braveyellowtoad]

Thanks for sharing. Do you know of any auth providers that charge based on auth event (login / logout / password change / etc) rather than per user?

[mooreds]

The big cloud providers have substantial free tiers (50k MAUs). Cognito, Firebase and Azure AD B2C all have a similar free tier. After you go through the free tier, you pay per MAU ($0.005 per MAU, according to https://aws.amazon.com/cognito/pricing/ , I think similar for the other providers. For smaller players, I think Stytch is 10c/MAU/month, where an MAU is any interaction with the Stytch service (login in all the many forms). https://stytch.com/pricing has more.

You'll have to dig a bit deeper into each pricing page to determine what actions make a user 'active'. I'm not aware of anyone who does MAU calculations on a day to day basis; monthly rollups are the standard.

Some folks charge per MAU (FusionAuth does) but in a band (the first 10k MAUs for a FusionAuth paid version are all one price).

HTH.

[braveyellowtoad]

Thank you

[sebmellen]

IMO https://ory.sh has completely changed this calculation. With the help of Ory Kratos it makes sense to roll your own auth.

[mooreds]

Do you mean to use Ory Kratos in a self-hosted manner? From a brief look it seems like you aren't rolling your own auth when you use this, but rather integrating it into your application.

What am I missing?

[sebmellen]

Kratos is not a complete Auth solution - if you self host you still need to write your own UI. We built another layer over it to handle RBAC and organization management. But at least Kratos covers all the complex crypto and security items related to authentication (not authorization, which I consider to be a part of “auth” writ large).

[mooreds]

Gotcha. There are still security concerns with the UI, but I agree, offloading the heavy lifting of password hashing, preventing enumeration attacks, and algorithm selection to a dedicated system makes sense.

Authorization is a whole other ball of wax. You can sometimes get by with RBAC, but it is far more often entangled with business logic. I've seen a set of new companies that offer outsourced authorization like permit.io and cerbos, and for an app of a certain complexity, think they are worth evaluating.

[akajla]

Building and maintaining UIs for RBAC and org management (including self-service, user-facing UIs) isn't trivial. That's why we built it into Warrant. We handle basic authz schemes like RBAC as well as fine-grained authz: https://blog.warrant.dev/introducing-the-self-service-dashbo...

[sebmellen]

We’ve found one of the biggest issue with RBAC services to be the integrations with our tech stack. Building the RBAC system ourselves helped it be congruent with our stack.

[mooreds]

That's cool. FusionAuth has a self service function: https://fusionauth.io/docs/v1/tech/account-management/ but it is limited to user profile data, rather than roles and permissions.

How do you prevent a user from assigning themselves roles they shouldn't? Is there some kind of cage preventing escalation?

[akajla]

The self-service dashboard is scoped only to privileged users (typically account/tenant-specific admins like IT admins) that have a specific permission.

[saluki]

Don't outsource your auth, auth is a solved problem for every framework worth using for the rest of your SaaS.

Don't outsource critical functionality.

[subbu]

This, totally. I manage a large B2B CRM with complex user-auth requirements and we use an off the shelf provider. It was an easy decision when we began, but now it has become a bottle neck in many ways. As your application becomes big you need a lot more customization to your auth logic. Large customers have specific customizations that off the shelf auth providers don't provide, or make it complex to implement. Over time auth and RBAC becomes crucial to your application. Engineering effort required to read through your providers documentation and implement workarounds exceeds a purpose built, native solution.

[moneywoes]

What about next js auth

[mooreds]

If it fits with your tech stack, definitely worth evaluating.