Leçons apprises : La solution d'authentification parfaite n'existe pas

“I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.”

- Abraham Maslow

Abraham Maslow developed a concept known as the law of instruments, or Maslow’s Hammer.It’s a cognitive bias that involves the over-reliance on a familiar tool. And It’s something I’ve become more aware of as I’ve grown in my career as a developer.

When it comes to implementing authentication & authorization, developers are usually torn between choosing from a number of third-party services, or rolling their own. In the beginning of my career as a developer, I went through cycles of attachment to different authentication services. Every time I discovered a new service or tool that I liked, I made it my “hammer”, and consequently I approached every project the wrong way.

Currently, I work as a community engineer at Memberstack. I believe wholeheartedly in our mission to simplify authentication and payments in websites and applications. But even I know now that Memberstack is not the "holy grail" solution to user authentication or payments (even if it feels that way sometimes).

The truth is, the perfect auth solution doesn’t exist... at least, not in an absolute sense. It’s all about picking the right tool for the job. Once you realize this and apply it to your work, you’ll find that you become a better engineer and the things you build become better too.

But making choices without bias isn’t always easy. So, how exactly does one learn to objectively pick the right tools for a project? Especially when it comes to important decisions like user management, authentication and payments? And how can you avoid the pitfall of Maslow's Hammer in the process?

It starts with 3 principles:Know your project, know your tools and know yourself.

In the following sections, I’ll break down these 3 principles and how they’ve helped me make better choices in my work.

Know Your Project

The first step is knowing your project: the requirements, goals and limitations.If you don’t know these details, you probably won’t pick the best tool for the job. Sure, you might pick something that works, but it won’t objectively be the best.

One way to gather this critical information is learning how to spec out a project. This is a powerful process, and one I often underestimated at the start of my career.

When you define project specifications, you are forced to consider things like:

• Timeline constraints
• Budget
• Security needs
• Requirements from UI / UX
• The tech stack and overall architectural strategy
• and much more

When you start exploring these topics, you end up defining parameters that will impact the technical decisions you need to make. Once you know your project’s needs, you can start exploring solutions.

Know Your Tools

When it comes to picking the right tool, there’s two key things that will have an impact on your decision making: The breadth and depth of your knowledge on all of the services and tools available.

Breadth

This refers to how many services you are aware of. Having more awareness of (and experience with) more tools lessens like the likelihood of latching on to one solution.Over the years, I’ve tried numerous authentication services: passport, next-auth, Netlify Identity, Magic, Clerk, Supabase, and Memberstack. I even tried rolling my own auth a few times. Some solutions I had to revisit when I gained more experience.  But as I grew, so did my arsenal of tools... and my confidence in them.

Depth

This is how well you know each service - what it has to offer, how well it scales with your needs, etc. Possessing this depth of knowledge is extremely important because it helps you make better judgement calls on things people don’t always think to evaluate: like vendor lock in, security, flexibility, etc.

Vendor lock-in and scalability are big things to consider. When your product grows and evolves, sometimes the architecture needs to evolve with it. This could mean replacing services, including the auth system you started with.

Ultimately, it pays to learn new technologies and frameworks. Learn their strengths and limitations. You don’t need to know every service or be an expert in each one, but you should know enough to have confidence in your selection. Just be careful not to obsess over new and exciting technology too much. Shiny object syndrome can kill your productivity.

Lastly, remember that no 3rd party service is perfect, because it wasn’t uniquely designed with your project in mind. But when you know what services are available and match their features up against your project requirements, you can pick the right tool for the right project at the right time.

Know Yourself

Once you know your project’s requirements and the auth services that are available to you, you still need to pick the right one. But how do you know for sure if you can trust your instincts? One of the biggest things that can prevent you from making the right decision is attachment.

When I first started learning modern development,  I was convinced that Firebase was God’s gift to developers. I got comfortable with everything they had to offer, including the Authentication feature. It’s safe to say I used Firebase in every single project for a year.

Then a colleague got me hip to Auth0. He said it was a gamechanger and explained how it would solve the limitations I encountered with Firebase. So we selected Auth0 for the project assuming it was the best tool for the job. Spoiler alert, it wasn’t. It was eventually deemed a technical debt that we’d want to eliminate in the future. Auth0 is awesome and incredibly powerful tool, but in this case, it simply wasn’t the right one for the job.

As I started learning new ways to implement auth either by choice or obligation, I realized that my attachment to certain technologies was holding me back. Sometimes I was attached because of product loyalty, other times because I didn’t know or wasn’t comfortable with anything else.

One way to lessen attachment is to get familiar with other options. This is something that will happen naturally as you take on more projects and get more experience. But you can also set intentional time to evaluate new solutions. I personally allocate 5-10 hours a month exploring new services, tools and frameworks that I believe would add justifiable value to my professional development or future projects.

Once I learned to let go of limiting attachments and approach all of my technical decisions with objectivity, I became a more credible problem-solver and my career took a turn for the better.

Putting It All Together

The most important thing to remember is that when you know your project, your tools and yourself, then you have all the context you need to make the most informed decision.

But when you over-rely on a single solution, you risk approaching problems in ways that are not always the most efficient.  Not only is this counter-productive to your growth as a developer, but it can also impact the success of the products you build.

So be objective, be open to evolving and don’t be afraid to level up your toolbox. Not every problem you encounter needs a “hammer” anyway.