Why outsource your auth system? | Hacker News Reader

Why outsource your auth system?

fusionauth.io

68 pointsmooreds84 comments

Which "auth" would that be? I get the feeling the article means authentication only, but halfway through it says "When your [..] authorization systems are down". Outsourcing your authentication isn't that much of a problem, especially in the context of decentralization of services. But authorization is rather tightly coupled to your service, and outsourcing that part would be much more of a challenge -- keeping authorization rules up-to-date with external systems is a difficult dependency management problem.

But regardless of which "auth" was meant, I feel this part is dangerous:

Auth may be unrelated to your core competency

No, please no. Both authentication and authorization must be considered a core competency for every online service, even if you decide to partly outsource it. You can't afford to have blind spots there.

Then you should also group the database in your core competencies and would likely need to consider building this yourself. Or the OS. Or the web framework. Or the wire protocols.

Sure, this is hyperbolic, but it does illustrate that not everything is a "core competency". There are always tradeoffs and decisions when it comes to software.

In my opinion, authentication and authorization are likely not core competencies for 99% of businesses. They are simply capabilities that just need to work and the business doesn't need to own them. This is the same with the database. Using a tool like FusionAuth, Keycloak, or SuperTokens will cover all of their needs.

I think @tremon is just getting at that auth must be considered critical, and thus you should maintain some level of skill and competency to ensure you don't get blindsided.

Perhaps the distinction is just because something isn't a "core competency" does not mean it is not critical. And just because it isn't a "core competency" doesn't mean you can afford to be ignorant on the topic.

That seems silly though. It is for this very reason you "dont roll your own crypto". _Because_ its critical, and _because_ others can handle it better when thats what they are focused on.

Never roll your own crypto, but you should damn well know how to use the library properly.

For most businesses, the database is a required part of the functioning of the business. That means:

- the database must be secured against unauthorized or improper use

- the database must be accessed efficiently

- the database must have some degree of resilience

- the database must be recoverable

- the database must be available

Each business will have different weightings for these properties -- does a dating website care more about database security than a bank does? -- which will lead to different decisions about who should own and manage the DB.

But a business is, absolutely, a group of people who are doing things together. If you can't identify, authenticate, and authorize those people, you don't have a business. And if the database that stores that information isn't among your highest priorities, I think that business is rather misguided.

Exactly. And most businesses "outsource" their database. They might use PostgreSQL for free or they might pay Microsoft for SQL Server. In my opinion, this is analogous to auth.

It's critically important that my office doesn't burn down, but that's not my business's core competence.

it's also critically important to your neighboring buildings that yours doesn't burn down. we have a fire inspection regularly that comes and inspects for common causes of fires (electrical wiring, plugs, etc) to help reduce possibility of a fire. it's not our core competency, and we have to allow a specialist access to our business to help mitigate problems, both for us and people around us. Should we have some sort of analogous municipal data security inspectors?

Nailed it.

What, you want every company to continue storing passwords themselves in crappy ways and reinventing the same wheels?

> But authorization is rather tightly coupled to your service, and outsourcing that part would be much more of a challenge -- keeping authorization rules up-to-date with external systems is a difficult dependency management problem.

Strong agree. We're trying to strike the right balance with this problem with oso [1] (I'm a cofounder). By letting you separate the authorization logic from your code, and doing a lot of the thinking for you (how to design + implement roles etc), but ultimately the data *stays in the application*. There's such a blurry line between authZ and business logic that it doesn't make sense to fully outsource it.

[1]: https://www.osohq.com/

As a startup with 2 engineers, yes, we use Auth0 and love that it handles everything for us at the moment.

Especially since we have to handle b2b clients who have their own SSO, etc.

Are you on their startup plan that allows you unlimited "Enterprise Connections"?

I'd be very careful with how their pricing impacts your business as you increase your B2B clients with Enterprise Connections.

I'm honestly not trying to pitch you on anything, but when you outsource your auth* to a provider, you must consider the long term costs based on your business model and theirs.

Do you have an exit plan?

Gotta have a good exit plan. I originally used Mozilla's authentication system, which I can't remember the name of, but they got rid of it.

Mozilla Persona, for anyone curious: https://en.wikipedia.org/wiki/Mozilla_Persona

I LOVED that. Persona was a profoundly disappointing product cancellation.

Agreed.

We use auth0 at work and I've thought about it. With time given most users are SSO based, it's probably doable but annoyingly so over a month to move to another service. Not that we would want to.

Outsourcing auth is acceptable for saas customers. For consumer apps it's probably not a good idea, pricing models typically don't seem aligned in your favor for that.

The only thing that would be hard to migrate is if you store passwords in Auth0 - you would have to reset everyone's password no?

I once did a migration of an auth system by having the new system attempt an auth against the old system if there was no password hash saved in the new one. If it succeeded, it hashed the password and saved it. Seamless for users.

Obviously the old system isn't going to stick around forever, but you can get a good chunk of the passwords migrated this way.

> I have never seen a major auth provider compromised

Linkedin, https://en.wikipedia.org/wiki/2012_LinkedIn_hack

Yahoo, https://en.wikipedia.org/wiki/Yahoo!_data_breaches

Or if we don't limit it to just data breaches but include compromises that would have allowed a full account takeover of any account using this identity provider in a third party app:

Apple, https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-a...

Also it's strange for a minor auth provider to promote "major auth provider". Seems that would drive away potential customers.

Lots of good points but ‘outsource’ here can mean a variety of things.

We have SuperTokens (self-hosted or SaaS I think) and Keycloak (self-hosted only if I’m not mistaken) so most people don’t need to ‘roll their own’.

But would I outsource the essential gateway to my service? Unlikely for the moment.

Agree that "outsource" can mean different things. If I'm building a rails app, I should "outsource" authentication to Devise or Omniauth (typically). There are lots of great options, libraries and services, commercial and open source, self hosted and operating as a SaaS.

What I always want to avoid is anyone running "create table user ( id int(32) ... )".

> But would I outsource the essential gateway to my service? Unlikely for the moment.

Do you outsource the operation of your database? Some people would never do that, as they consider it core to their business operations and have the skills to run it. Others evaluate the options and decide that outsourcing running a database makes sense for their situation.

Engineering is all about tradeoffs.

> What I always want to avoid is anyone running "create table user ( id int(32) ... )".

Hum... I have never seen a system that could ditch a user table, whatever authn and authz schema it's using. (An independent authn service only makes it more complicated, because you now have redundant user tables.)

But a password column can be avoided.

Fair point, as most systems need to refer to users for internal relations, though with a fully outsourced solution you can get by referencing the external user ids.

As you suggest, I should have mentioned the big things to avoid are password hash and salt columns.

So storing password hashes is better done in a file than in a database?

It's better done by some code that you (or anybody not focused on authn) didn't hack-up on half a day.

Knowing that the hashes are not stored on the database that most of your external interfaces access can bring a lot of tranquility, but you'll get some PII there anyway, so I'm not sure that tranquility is warranted.

A data point for hosted Keycloak offering: https://www.cloud-iam.com/

No connection to and no opinion of the offering - just noting its existence.

I absolutely hate hand-rolling auth for every new SAAS system. I advocate e.g. Auth0 everytime, because no one gives a shit about logging in. It is such an inconsequential part of the product offering, yet it consumes _so much_ time and energy because of the (justified) importance of "doing it right".

I understand the SAAS offerings are relatively expensive, but its just such an engineering sink. Especially once you start getting into SSO, MFA, and the like. So yes, I'm 100% in favor of outsourcing it.

EDIT: Authorization is different. Absolutely keep that in your database if you can.

For 99.9% of businesses, don't roll your own auth. Just don't do it. Use an auth service.

I think you are assuming a certain _type_ of business? Most web applications have moderate requirements... 1 code repository, 1 server, 1 database, dozens or maybe hundreds of users.

This service is dealing with stuff like OAuth, SAML, two factor, logging, monitoring, scaling and apparently even does authorization (from skimming) and more.

In other words, tons of stuff that many businesses don't need or want.

There are certain fundamental security requirements that don't change, regardless of whether you have 10 users or 10m. If you have a breach, you have a breach. Numbers of repos, databases, servers have very little (nothing) to do with the security requirements of storing personal data.

Yes and no. Complexity, source code volume, data volume and amount of users naturally introduce failure states that are not found in a simpler system. They also reduce your facility for reasoning about the whole, and the amount and type of assumptions you are allowed to make.

Google, an indie game, a SaaS, or a custom web app shop all have different security engineering requirements, including authentication, often per project.

Also outsourcing auth and not having full control over it is not feasible or even allowed for some domains or projects for a multitude of reasons. Not to mention that using an external service has at least a constant complexity cost.

That said, these kind of services are definitely worth considering for many. There is something to be said about advantages of specialization and cost-benefit as well. Reliability is not optional for an auth system, and I'm sure these engineers are really good at what they do. However the challenge would rather be convincing business, not engineering.

If there is something I would not delegate it’s my authorization/authentication flow. That’s just too much of a risk to depend from an external service for such a critical part of my systems.

This is an attitude that makes absolutely no sense to me. Ask yourself - can I afford to get this wrong?

The risk of your home-rolled auth, with all the edge cases and requirements that go with it, vs. outsourcing to a company who's entire reputation relies on doing it properly with an army of experts, running on enterprise-grade architecture, with round the clock support/updates/ops?

Are you seriously saying that you can roll your own auth better than Auth0, Fusion etc. can do? And that the hours startups spend on setting it all up vs. an afternoon wiring in an auth-as-a-service provider is time well spent?

If you're a small company, don't risk it, don't invest time in it, just buy it it and plug it in and know that it's all enterprise-grade under the hood and you're covered (far more than you could ever afford to be).

If you're a big company, and you've done the maths and figure that the risk/effort vs. expense is worth it, fine.

I don't think your parent poster wanted to roll their own auth library. They were disagreeing with using a SaaS for it, that's how I read them at least.

I don’t need all the features Auth0 offers. And I can for sure implement an auth system, that’s a well known and solved problem since a while.

We've taken a slightly different approach to this at WorkOS. (I'm the founder.)

We decided to handle authentication but explicitly _not_ user management or authorization.

This means our API is essentially just an OAuth2 wrapper around enterprise identity systems like Okta, Microsoft ADFS, generic SAML, OpenID Connect, etc. We don't require developers to migrate users into WorkOS, handle access policy, or "own" the user object. The primary user database always stays in the developer's app and WorkOS just serves as an authentication gateway. This turns out to be much more flexible, faster to integrate, and ultimately what developers actually want when adding advanced authentication strategies to their app (like enterprise SSO).

So I guess what I'm saying is this article title is a bit of a misnomer. It's actually about outsourcing your user management and identity infrastructure to FusionAuth, which is a much larger decision with architectural effects. And unfortunately that results in strong vendor lock-in to a platform like FusionAuth (or Auth0).

(For anyone curious, you can see more about the WorkOS approach here: https://workos.com/docs)

Any recommendation for an open source, self-hosted auth solution would be good (useable with c++, javascript etc)? OAuth 2.0? Keycloak?

(I should disclose upfront that I'm the founder of FusionAuth)

The core of FusionAuth isn't open source, but a good portion of the code built around the core is open source. It is free and has a large, growing community and integrates with any language.

Plus, you get the benefit of a having a company behind it that is constantly improving and updating the product.

I'd be happy to talk more about our licensing model and why we chose it if anyone is interested.

Is the self-hosted solution limited in some sense or feature complete?

It has all of the same features as the Cloud version, including unlimited Enterprise Connections (SAML and OIDC) for free.

The only features that required a paid-Edition are: Connectors (connecting to LDAP and other backends), Advanced Registration Forms, and Breached Password Detection.

We are adding additional paid features as well, but our Developer Edition is reasonably priced. $125/month to start and that gets you up to 10,000 MAU. You can also test drive Developer Edition free for 14-days.

I have used FusionAuth for a few projects now, both personal side projects and work projects. My only qualm is that it is Java based and relatively heavy on the laptop if you’re running a local dev instance in Docker. I love the product though, the support is fantastic and the docs are straightforward. I’m a big fan, great work FusionAuth team.

Not open source, but free as in beer: https://curity.io/product/community/

It's a complex server, but if you need to connect to lots of third party systems it may be a good choice as it has support for all sorts of things and its plugins are open-source (e.g. BitBucket plugin: https://github.com/curityio/bitbucket-authenticator)

Yup, Keycloak. It's certainly a batteries included solution but my experience so far has been quite positive. Apps deployed have been for small provincial govt ones with individual app user bases varying from 1 or 2 users to 30k (size of the provincial public service). Keycloak does the OAuth2/OIDC work using the govs active directory for the identity provider. Keeping my eye on Ory as a perhaps more ala carte solution. edit: added Ory comment

The ORY stack: https://www.ory.sh

Thanks! Can you recommend any C++ client example to use the ORY stack?

The ORY SDKs are auto-generated using OpenAPI, so you could probably request one or generate one yourself (https://github.com/ory/sdk). I just put in a request for a Rust SDK and was able to auto-generate one locally for testing purposes pretty easily.

Any idea when will an official Rust SDK exist? Very interested. A link with a tracking issue / PR would also be good to have.

I'm currently investigating this area and have been recommended Parse and Supabase

Looks like C++ client support is still a request? https://github.com/supabase/supabase/discussions/5

Does it not have a plain REST API you can use? I've not looked into it in detail yet

I don't know that I'd even refer to this at outsourcing. If you can run it on premise, it is just "not building it yourself".

The sweet spot is using some well known library. A classic in the Rails world is Devise. There is usually one for any language or framework.

A sweet spot only is as much as the code is already written, but there's a huge amount of ops and security work that goes into rolling your own auth.

For 99.9% of businesses, don't roll your own auth. Just don't do it. Use an auth service.

Is there a good one that integrates with Express?

Passport is an Express middleware for authentication. It supports pluggable "strategies" for supporting different types of authentication, from basic username/password to OAuth and many others.

https://www.npmjs.com/package/passport

Passport. It provides a lot of authentication schemes

Yes, this is an excellent choice as long as all of yours apps live in the Ruby world.

Actually I built a single sign on system for a Rails app and a WordPress site many years ago, based on Devise and probably (can't remember) some PHP code on WP. Probably also a Rails+phpBB SSO. They were meant to be short lived services and luckily they did. The reason is that in a mixed language / framework environment it's better to have some centralized authentication and authorization service and a standard API to access it. Having to write and maintain N adapters is going to take a toll on the development team. However I never self hosted a service like that so I don't want to give any suggestions about what to use.

In the past I always rolled my (our) own auth but in recent years, it is so much easier to offload this to another system for so many reasons including just being more secure (policies, MFA, oauth2 pkce etc). I've used AWS Cognito which is probably one of the cheapest along with Auth0 and Okta.

I've even migrated from my (our) own to another provider and back, including provider to provider without an issue. I was initially concerned with vendor lock-in, but it hasn't been a major problem so far. With most of them it is fairly easy to migrate without any interruption to your users (including MFA!).

My reluctance to using a hosted auth system (vs using passport or similar) is vendor lock-in. My impression is trying to move later would reset all passwords and oauth connections to zero. Am I misunderstanding this / should I not really be concerned about this? Would definitely make my life a lot easier.

It would be great to get an idea about the experiences of companies that had to migrate out of such a solution after they got a lot of customers that use SSO etc. We started on Auth0 but left when their pricing model started to influence architecture decisions and realized how rough migrating out could be.

I don't see anything in this article that's specific to auth. Why not entitle the blog post "Why outsource?".

The points made in the article seem equally applicable to any piece of a software service. It effectively boils down to this first line of the Maintainability section:

> There are trade-offs here

Well, for one because it was posted on an outsourced auth provider's website :) . (Full disclosure: they are my employer.)

Seriously, though, while the headlines (cost, maintainability, etc) are applicable to any non-core software functionality, the arguments below the headlines are focused on authN/authZ. Security, standards compliance, auth breach consequences: these are all factors that matter more for outsourcing auth than they might, say, outsourcing your brochure website hosting, or outsourcing analytics. All outsourcing decisions will involve some of these dimensions, but with a different emphasis.

> Security, standards compliance, auth breach consequences

I would argue that security, standards compliance, and breach consequences apply to everything.

> but with a different emphasis

This is fair though.

TL;DR: We use Keycloak with millions of users and it works fine. You don't have to shell out for outsourced auth if you would consider a self-hosted solution. You also don't need a team to run it.

I work for a large organization that incorporates multiple other businesses with millions of users under their own domains. After using Auth0 and other SaaS auth providers, we've settled on using Keycloak and are happy with it. Cost, security (you own all data) and extensibility were the driving factors.

+ If you have Java developers, you can extend its features via SPIs. Worked great for some custom authentication and migration flows we had to build for legacy systems.

+ It comes with batteries included: Install it, hook it up and for most cases you are done.

+ Redhat seems quite invested in it, so it has corporate backing. This could also be a bad thing, depending on your view of Redhat and which direction they take the product.

- It is a big pile of java. Since it works so well, even in cluster mode and containerized, we've never had to dig into its internals. But it is still a big pile of java. They are working on a rewrite with Keycloak X, but that is still in development.

> + Redhat seems quite invested in it, so it has corporate backing. This could also be a bad thing, depending on your view of Redhat and which direction they take the product.

Yes, true. :-) We'll see if IBM feels the same way.

https://www.servethehome.com/red-hat-goes-full-ibm-and-says-... http://techrights.org/2020/08/02/red-hat-layoffs/

>It is a big pile of java

It looks like Keycloak.X is going to be a slightly smaller pile of java :)

https://www.keycloak.org/2019/10/keycloak-x.html

You say you haven't had to dig into the internals at all, but has having a "big pile of java" even containerized, affected your operations significantly?

I've run it inside a container and not experienced tremendous issues with RAM or CPU usage, but this is for very few auth calls per day.

Also, I needed to apply some not-obvious environment / config changes to make it work behind HTTPS and inside a container without /dev/random being remounted.

Awesome, thanks for the on the ground feedback.

Yeah, no issues here either in containers. We did have to make some custom tooling at the time to get all configuration files under source control though

Not really. But we also haven't had any issues that required taking a closer look. We're used to hosting JVM stuff since our devs produce a lot of scala code.

I'm looking forward to them switching to Quarkus, which will make it more ameneable to be run in containers.

Thanks for your insight!

Do you happen to have experience with a large number of realms in Keycloak? I was looking at it a while ago and found conflicting opinions on how suitable realms would be to model multi tenancy in a saas. Mainly for performance reasons I think.

Hmm no, sorry. We only ever had a small number of realms. I would be cautious and test it with the number of realms you intend to use it with. We used locust (https://locust.io/) successfully to do loadtesting on a few of keycloaks auth flows.

Have you had any issues with reliability or downtime in running it yourself? Or any use cases it hasn't supported? Interesting to hear you're running it with so many users!

No issues with reliability.

We did some load testing and noticed that the first thing to become a bottleneck was the database, after running 4k concurrent logins or so. I suspect we'd have to introduce propper postgres connection pooling to overcome that (we were running a single postgres instance).

You do need to watch out for the way it caches things though . I suggest to read the relevant documentation, as it works a bit differently in cluster mode https://www.keycloak.org/docs/latest/server_installation/#_o...

One thing to keep in mind as well is that if you create an SPI extension to cover a spicific usecase, you'll have to add your own metrics collection. It was a bit of overhead to configure in prometheus, since you'll end up having a metrics endpoint to scrape for each SPI.

> Why outsource your auth system?

To make it easy for the spooks to backdoor your clients systems?

I particularly like this one FTA: "When your competitors’ authorization systems are down at the same time yours are, nobody blames you for it, but when you’re the only company having issues, you suffer reputationally. No matter what your outsourced auth system is (FusionAuth, Cognito, AAD, etc), you can be almost certain that you won’t be alone in the event of an outage."

Ok...

They give the real reason: because if your auth provider is breached other clients will be as well and that diffuses the blame. (non)-security by herd instinct.

So... This is Juiceroo is saying you needs its expensive juicer to get juice?

Reply on news.ycombinator.com