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.
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 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?
> 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.
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.