Pivoting from Auth0 to PHP Symfony

These days when creating a system there are many different ways of setting up authentication. However the main options boil down to: a self made solution, a Aaas solution (authentication as a service) or a combination of the two, Aaas has become more a lot popular recently, with companies like OpenAI opting for this. And in the space of Aaas the most recognizable name is Auth0 (Partly i think because of OpenAI).

The reason we needed authentication was to verify user in node.js. Node being our service for communicating between the user and the LLM. In this article we'll go over: why we went for Auth0, the problems we ran into, and why we pivoted to Symfony

Why we chose for Auth0

Starting out with Browsely we obviously wanted to get the product to the market as fast as possible, so we opted for what seemed like the easiest and quickest solution Aaas and specificly Auth0. Here is a list of perceived pros of Auth0:

• Quick to implement, because we wouldn't have to build much
• Free to get started
• Social login off the bat
• No need to setup email and for: password reset and registration

These points seemed very appealing so we got started with implementing it and we very quickly started running into problems.

The problems with Auth0

When implementing Auth0 the first problem we ran into is that its existing JS package is not really meant to be used for a web extension. From some things we came across online we found that supposedly in the past they did have support but it since has been removed. This meant we had to implement quite a lot of the authentication layer our self's. And because the JS package is meant to be used plug-and-play without much customization we had to back engineer it quite a bit to get it to work in a web extension. But eventually we did get it to work and did end up working as expected.

Now the next problems arose when building the subscription layer, which we decided to do with Stripe as payment provider. This created two issues 1. We now needed to store user data in two external systems, both of which needed to be kept up to date. 2. The user would now have to log in to our portal and in to the extension separately which we thaught would feel clunky. We did make a start on trying to solve the first problem but very quickly we felt the effort required to implement this neatly was to great at this stage in the project. And it was at this point we decided to pivot.

Another problem not mentioned before is the pricing of Auth0 as we started using it we found the free packed permits quite a lot, and the payed plans seemingly less by comparison. Overall it was unclear when you'd have to pay and what you'd have to pay for. This problem was less pressing but one that could blow up at a later stage.

A quick summary of the problems we ended up having with Auth0:

• Messy to implement in to an extension
• Messy to set up with Stripe
• The user would have to login manually in two different places
• Vague pricing

The pivot to Symfony

Something i have to mention: our website was already built in Symfony. Now i hear you ask, why Symfony? That's simple, we know Symfony, so we can build fast and know what we can expect from it, now and moving forward. So logically we would migrate the whole auth system to it.

One of the things we learned form our initial Auth0 implementation that we really liked was JWT. A protocol that would make centralized authentication much easier. So our setup would be: Symfony creates and signs a JWT and send it to the user, the user would send it with their request to node, node verifies based on the public key.

If you want more technical information about how we setup Symfony as a JWT provider lookout for a future article where we go more in depth. Since we found there currently is not much information on how to do this with Symfony.

Now, this setup is essentially the same way Auth0 works the only difference being that implementing this yourself gives a lot of liberties and options, allowing us to resolve most of the problems we had with Auth0. The implementation is much cleaner and allows for the user to simply log in to our website and they will automatically be signed in to the extension. We dont have to sync user data between both Auth0 and Stripe. And the pricing is very stable and predictable this way. The only downside thus far has been the lack of social login off the bat.

We are now very happy about our decision to pivot and have learnt a lot from the whole experience.

Conclusion

What have we learned. And what can you learn from this.

1. Stick to what you know. Building the auth system in Symfony ended up taking about as much time as setting up Auth0. Howerver the result is alot more robust and ready for future developments.
2. Don't outsource to save time. This is something we had already experienced in the past but at a small scale outsourcing usually costs about as much time if not more as doing it your self. There are exceptions like payment providers for example but generally, if you can do it yourself its usually faster.
3. Control is important. Keeping as much of your product in house as possible especially starting out. Its easier to outsource something at a later point than it is to take something back.
4. Be ready to pivot If you feel like a solution is causing more problems than its solving its most often time to look for a better solution.

Also i quickly want to mention that this article is not against Auth0 or Aaas in anyway, we think there are very valid use cases, especially for more traditionally structured web-apps.

---