Auth0 vs Ory Kratos

with our Junior Software Engineer Matt Barrett.

As we continue to extend our range of products, Matt compares two potential authentication solutions — Auth0 and Ory Kratos.

Building a Platform

As we continue to build out our Phlo Connect platform and introduce new digital prescribing products, having a safe and secure way for our partners to confirm their identity and log into our products is a key focus.

While building an end-to-end user authentication solution in-house is possible, building upon an already established solution helps keep build and maintenance costs low and ensures we stay at the forefront of best practices.

Selecting an Authentication Solution

After an initial appraisal of the myriad solutions on offer, we decided to take a closer look at two products from opposite ends of the market: Auth0 and Ory Kratos.

Auth0, a fully hosted cloud solution, sells itself on its ease of implementation. The Quickstart guide quotes a 15-minute timeframe to get a login flow up and running on an existing React web app. This is possible as Auth0 provides authentication screens out of the box — there is no need to build your own login and registration screens. This simplicity does come with some drawbacks, however, such as limitations on the level of customisation, and an ongoing cost that grows as your user base scales. Auth0 is managed via an online dashboard, through which you can tweak security settings, user flows and other configuration parameters.

Ory Kratos, on the other hand, is an open-source, API driven solution to user authentication. It doesn’t include prebuilt authentication screens and needs to be self-hosted (unless using Ory Cloud, a cloud-hosted variation of Ory Kratos). While this means there is an overhead to setting Ory up, it also allows complete freedom to build your own authentication screens and fully control user journeys, with Ory only responsible for its highly specialised purpose.

Essential Functionality

The first thing we needed to confirm was that both products were able to meet the needs of our products, and so defined 7 key acceptance criteria:

· Customisable UI
· Configurable Password Requirements
· Session Management
· Email Verification
· Phone Verification/2FA
· Account Recovery
· Supports migrating existing login

On the whole, we found that both Auth0 and Ory would be suitable for our purposes, either containing the functionality we needed as standard or allowing us to add it ourselves. There were a few caveats and differences separating the two in key areas though, and these became our decision points.

Customisable UI

With Auth0 the scope for customisation is limited. The login box itself is a widget which you can customise using the dashboard — but the only options available to edit are the logo (which displays above the login fields), and the button colour.

The background colour option controls the colour of the page surrounding the login box. This is further customisable using the Liquid template language. You can read more about the specific ways in which Auth0 allow you to edit this page in their documentation here. Ultimately, you are only able to use Liquid to adjust the content displayed around the Universal Login widgets, meaning the layout and components that make up the login form cannot be modified.

By contrast, Ory Kratos places no limitations on your UI. While you will need to build it from scratch, you have complete freedom to design your login page as you see fit. As long as your text fields/buttons are correctly connected to Kratos, their appearance is irrelevant to the functioning of the authentication process. As design and UX are core to our development philosophy at Phlo, this extra freedom was a major factor in our decision-making process.

Configurable Password Requirements

When settling on our acceptance criteria, we found the ability to configure our password policy to be essential, and this is another area in which Auth0 and Kratos differ.

Auth0 comes with 5 pre-defined password strengths, allowing you to select which level to enforce. The levels are as follows:

· None (default): at least 1 character of any type.
· Low: at least 6 characters.
· Fair: at least 8 characters including a lower-case letter, an upper-case letter, and a number.
· Good: at least 8 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character.
· Excellent: at least 10 characters including at least 3 of the following 4 types of characters: a lower-case letter, an upper-case letter, a number, a special character. Not more than 2 identical characters in a row.

Ory Kratos however only has 3 parameters to configure when it comes to the password policy, two of which are only configurable in the sense they can be turned on or off. They are: a minimum length, an identifier similarity check (which checks to see if the password is similar to the user identifier), and a ‘Have I Been Pwned’ check (which checks if the password has been found in the Have I Been Pwned database).

We were initially concerned that this may not be enough flexibility, but Ory has published their reasoning and research into Password Policy Best Practices here. Reading this resulted in us rethinking the initial importance we had placed on stringent password requirements.

Migrating Existing Accounts

The third area the two products notably differed was in the methods offered for migrating users across from an existing database. When coming to a decision, we wanted to remain open to the possibility of using the chosen product for login across the whole Phlo platform — meaning migrating user accounts over from our existing solutions. Both Auth0 and Kratos can support this, although the process is simpler with Auth0.

Auth0 supports automatic migrations, sometimes known as trickle or lazy migration, which can be enabled after connecting your Auth0 dashboard to your existing database via their custom database connection interface. This will move users to Auth0 the first time they log in after integration has been set up, with no need to reset their password.

Migration in Ory is handled by feeding user data into the same endpoint used for account creation. This method supports hashed passwords encrypted using PKBDF2, Argon2 or BCrypt algorithms.

Both of these methods will appear seamless to an end-user, however, the Kratos migration requires additional work on our end, as existing data will need to be reformatted into an appropriate payload, and fed into the endpoint.

Making a Decision

After reviewing these factors as a team, we found the decision boiled down to the core principles of the two products, rather than the specifics (which both were able to handle).

Auth0 offered speed, simplicity, and support. It would be quick and easy to set up, and we would have access to their dedicated support team if we ran into any major issues. This came at a price, however, both literal (see below) and figurative, in the sacrificed design freedom and reliance on a third-party provider.

Ory Kratos offered the freedom to design our login flow exactly to our vision, using open-source software that we can host ourselves. While there is no dedicated support, the welcome we received on the Ory Slack was exceptional. All our questions were answered within minutes and we had a clear understanding of what the future of Ory looked like.

Despite necessitating additional upfront development time, Ory Kratos has won us over as a flexible and scalable solution with a strong supporting community.

We are currently working on an initial proof of concept using Ory Kratos and look forward to sharing our findings as we gain a deeper understanding of its capabilities.