Comment by KronisLV | Hacker News Reader

Comment by KronisLV | Hacker News Reader

Parent Full thread

> Building a product with so many dependencies feels very amateur, error prone, and prone to instability. Again, it's just a gut feeling from some old dude that has been doing software since the late 90s. Maybe it's just the way things are done nowadays.

I wouldn't call it amateur, but picking lots of SaaS tools or solutions is indeed a curious choice!

In some domains, that probably makes sense: you probably don't want to self-host an e-mail server and write your own software for handling mailing lists if you don't want deliverability to be an issue. You might not want to write your own chat solution or alerting solution, when there are off-the-shelf options that are good enough. Furthermore, doing your own auth implementations is somewhat risky, so even if you want to self-host things (though there are many cloud services), you'll probably still be served rather nicely by something like Keycloak. In addition, having your own CI runners or source management system (e.g. GitLab or Gitea) can necessitate certain amounts of maintenance work, as would self-hosting Mattermost/Rocket.Chat instead of just going with Slack and so on...

I guess there are SaaS options for almost every domain and which ones you deem necessary is likely to vary quite a bit! It's probably a matter of striking a balance between the expenses that engineering time for handling development/maintenance/problems yourself would incur, versus just paying someone else to deal with it, as well as who you'd rather hold accountable for any part of your system working.

I'm actually in the early stages of working on a video series about web development, where I self-host almost everything and it does feel like doing a lot of work to get even relatively basic systems online (e.g. no cloud load balancers, no vendor locked managed databases, no cloud monitoring/alerting solutions etc.).

> doing your own auth implementations is somewhat risky

This is a false dichotomy: people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own.

This is not to take away from your points (which I agree with), but for some reason I see many people thinking their only choices are signing their JWTs manually or using Okta.

> people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own

The problem is there's a trend to prefer hyped-up languages with little/no battle-tested frameworks like those so this is literally not an option for a lot of companies where their "backend" is a pile of hand-rolled shit on top of Express.js, FastAPI or other minimalistic framework.

It might be a technically possible option to switch over to one of those, but too many people would have to lose face (at multiple levels, from individual developers all the way to investors) so it will never happen.

> This is a false dichotomy: people can choose to use a framework that handles auth competently, such Django or Rails, no need to roll their own.

If you want a centralized auth provider across different services, then something like Keycloak is indeed a good choice, which is why I mentioned it: https://www.keycloak.org/ Of course, for the actual services, you should go with a standard OIDC/OAuth2 library, or something like that, even a proven JWT library if need be.

Having Django or Rails (or one of the supporting libraries, like Devise) handle auth and permission control for more self-contained applications is also fine.

I'd just like to caution against writing your own badly documented and badly tested framework for auth, along the lines of storing unsalted MD5 password hashes, or even doing certain controls client side (although I haven't seen this personally, I've definitely seen lacking implementations and have heard stories from others in the industry).

Why in the world do people use SaaS auth?

As you said, there are plenty of local options that you only need to run. It also has the largest risk of compromise and data leaking from any service you may use, the largest amount of potential lock-in, and the least need for integration.

If you take any property of a service that makes it a good target for off-shoring, and reverse it, you get auth.

Well, many reasons, to be honest. Yes, you can easily set up some local LDAP/AD/Whatever and setup some OIDC/SAML connectors.

SaaS like Okta, OneLogin, even Google Directory offer many things that you don't have to think about:

- If your organization doesn't use SCIM and you have headcount that requires HR, then your IT department is wasting time. You also probably will fail audit.

- How do you limit which users allowed to use a service that uses OIDC or SAML?

- Where is audit log stored?

- What's your SLA?

- Does it integrate with HR software?

- Does it restrict access based on location? Is there some logic to prevent a user from city X suddenly login from a city 3000 miles away?

- Do you have contractors? How do they access resources they need?

- Service accounts?

Sounds like BoxyHQ could be relevant here. Plug-n-play for developers that need to build enterprise features like SSO, audit logs, directory sync, privacy vault and other boring stuff that are required to be compliant.

100% free & self-hosted. It's Open source (Apache-2.0 license) [I am one of the co-founders, sorry for the plug]

> As you said, there are plenty of local options that you only need to run.

I think managed databases are a good analogy here. While I might run my own PostgreSQL/MariaDB instance, many out there won't be overjoyed at the idea of actually needing to run and manage the damned thing, as well as set up some kind of alerting and handling the need to eventually scale it up, in addition to backups and failover.

> It also has the largest risk of compromise and data leaking from any service you may use...

PII is definitely a big concern, even if something like password hashes aren't too useful on their own (provided that they're salted), though in cases like that it might actually make a lot of sense to utilize a widely used and tested solution that's specialized for this particular use case.

In many cases, thousands of people across the globe will be able to develop something and squash any bugs in it better than you might be able to do individually or with your own team, though there might be a few exceptions out there. Auth is probably not one of the cases where you want to write code without a lot of eyes on it.

> ...the largest amount of potential lock-in...

This is debatable: standards like OAuth2 and OIDC technically make many of the solutions and libraries way more pluggable and make it easier to choose between various implementations, depending on your needs.

Of course, something like Keycloak also has its own API (as do many of the cloud offerings) so if you build too much automation around a particular implementation, then that advantage partially goes out the window.

> ...and the least need for integration.

I'm not sure about this, it probably depends on your architecture. If you have a monolithic web app, then you probably don't need a separate turnkey/SaaS solution, whereas if you have an ever growing number of services, whilst you want to manage authentication and accounts against all of them centrally, then something like Keycloak (or one of the cloud alternatives) become way more lucrative.

That said, I'd still opt for self-hostable options whenever possible, albeit I also don't trust cloud based password managers and such, preferring something like KeePass instead. I've probably just come to a different conclusion in regards to usability/responsibility/features/security than some other people.

Sadly, there aren't that many good options out there at the moment, apart from Keycloak. For example, IdentityServer is promising, but went in a commercial direction: https://duendesoftware.com/products/identityserver#pricing

> I think managed databases are a good analogy here.

There is at least some work in managing a database. The risks are very similar, but at least there is some value in offshoring it.

I have never seen offshoring it being a net positive in terms of labor saved alone (it's way more work to make sure the managed database stays running than doing it yourself), but it can be positive in theory. It can scale down better in theory too.

> whereas if you have an ever growing number of services, whilst you want to manage authentication and accounts against all of them centrally, then something like Keycloak (or one of the cloud alternatives) become way more lucrative.

Well, Keycloak isn't a could SaaS. I bet the clould alternatives will give you all kinds of issues, starting at bad pricing (on that link, you will be enterprise before you can blink). But well, there is no reason at all to go and confirm it, the best they can do is to not add unreasonable operational costs over running your own, and just add some huge risks.

Reply on news.ycombinator.com