I've looked at various ways of logging in users and I'm wondering if I should write my own.

There are a lot of third party solutions that make it easy and cheap to get started, like Amazon Cognito and Auth0. But as easy as it is to get started, they all lock you in, make you reliant on their solutions and have terribly one sided user agreements (in their favor).

There are a some open source solutions that offer a complete experience out of the box, like Keycloak. It works but it's highly opinionated about flows like email verification and its freemarker templates would take a major effort to style as we want. ORY Kratos also comes to mind, but it's in the early stages and I don't want to rely on a project they I don't know at this point if it will be around in a few years. I hope it will because it looks promising.

Spring Security used to be an option but unfortunately their current solution is deprecated.

So... should I roll my own?

It seems like bad practice, but I find it difficult to find concrete arguments. If I google the question, I find arguments against in house authentication solutions like having to hash passwords and having to write features like email verification and password reset. However, all of these would be easy to implement, so these particular examples aren't convincing reasons not to create an in house solution.

But maybe there are a lot of unknown unknowns that I should worry about?

For instance, OAuth / OIDC + PKCE have some complex flows that I can't claim to understand. Maybe these are all things we need, or maybe they're not.

What are your thoughts? Is an in house authentication solution feasible? Or should I forget about it, bite the bullet and put an Amazon/Auth0 snare around my neck? Other solutions?

  • 1
    "login functionality" is a pretty broad description and it is not clear what you really need in the first place. But given your arguments so far I'm not sure that you have the knowledge and resources to write your own solution in the first place and make sure that it is actually secure. If this is true it would be a clear argument against writing your own. – Steffen Ullrich May 8 at 10:47
  • 1
    The purpose of this site is to provide answers on specific question. You are asking about opinions. Such questions are out of scope on this site. – mentallurg May 8 at 12:12
  • 2
    @Martin01478: "I'm asking for concrete arguments." - Not enough details are known to provide concrete arguments, neither about the specific requirements for the "login functionality" nor about your capabilities to implement one by your own and to maintain it yourself in the future. Solutions are usually not perfect but a trade-off with various advantages and disadvantages. And there are a variety of restrictions in real-life, i.e. business needs, time to market, available money ... and many of these considerations are unrelated to security (i.e. off-topic). – Steffen Ullrich May 8 at 12:53
  • 1
    @Martin01478: Rereading your question ... basically none of the arguments you provide is related to security. These are about price, availability in future, ease of use, user agreements, stage of development, ... . Valid arguments, but unrelated to security. Not considering security as the main point of decision (or even worse: not considering security at all) makes the question off-topic in my opinion. – Steffen Ullrich May 8 at 13:12
  • 2
    "having to hash passwords and having to write features like email verification and password reset. However, all of these would be easy to implement" Easy to implement? Sure. Easy to implement securely? Not as much. An advantage of using a dedicated solution or an existing framework is that they have likely already addressed common pitfalls that you may not be aware of. – multithr3at3d May 8 at 14:49