Auth0 Reviews

We use it as an authentication platform for our customers.

With Auth0, you can stop the effort of having to keep up with the progress being made in the security and authentication world, like better protocols, better encryption, and better ways to connect with other systems. It's all managed in Auth0. At the organizational level, you stop worrying about how to connect Facebook users to your application, or how to connect with a customer's internal authentication system to log in to your systems. These were questions that, three years ago, we decided to develop answers for ourselves, but with Auth0, each integration now comes out-of-the-box, and it's only a matter of configuration.

It's a very powerful platform. It has the ability to do the usual stuff, according to modern protocols, like OIDC and OAuth 2. But the real benefit of using the platform comes from its flexibility to enhance it with rules and, now, with what they call authentication pipelines. That is the most significant feature, as it allows you to customize everything regarding the authentication and authorization process. I would rate its flexibility between a nine and 10, out of 10.

For example, one way to authenticate into our system is to log in with Google. Our service is not one that you can simply sign up for through the internet and then start using. You need to talk with one of our technical account managers, sign a contract, and then we start everything for you. So when a user logs in with Google, it means that every user on the internet can log in to the system. We needed to find a way to know if a user was already defined in our systems, and otherwise, to reject him. We wrote a simple Auth0 Rule to get the user's email from Auth0 after he authenticated, and we then use an API in our backend system to check if the user is legitimate. In this way, we filter out all those who are not our paying customers.

In addition, we like the integrations that are built into Auth0. For example, it has a built-in integration with Zendesk. It's very easy to set up new SAML and SSO integrations with our customers, as it supports all IDPs out there, like Okta and Azure, among others. 

Auth0 also has a very rich selection of social connectors that allow users to connect with their social accounts. We mostly use Google, but they support many others. In addition, their user interface is very intuitive.

Lately, it looks like they have been very responsive to customer needs since they brought out the Organizations feature in the last year, which is a very nice feature that helps customers like us to manage our customers. It's targeted at enterprise-scale solutions, allowing us to manage multiple organizations within the same tenant. We are seriously considering migrating to this feature. It's a process, but we feel that it will better support the customer model that we have in Kenshoo. We also need to be able to support customized login screens with different company logos. All of that is supported by Auth0, so this probably would be a much more important feature for us than the rules themselves.

When they introduced the Organizations feature they did support different login screens per organization. However, they introduced a dependency between this feature and another called the New Universal Login Experience. The New Experience is a more lightweight login screen, but it is much less customizable. For example, today, we are able to fully customize our login screen and even control the background image according to the time of day. We have code to do that. But we are not able to write code anymore in the New Experience.

We really want to take the Organizations feature, but on the other hand, it is coupled with the limitations of the New Experience. That is why we have put the Organizations feature on hold. It is lacking some customization abilities.

I've been using Auth0 for approximately three years.

An important feature is the very good availability, the high availability. In the last three years, we have only faced one major outage in production.

For us, scalability is less relevant. Our service is not characterized by millions of users. It's not like Snapchat or Instagram where you need to deal with a massive number of users. In our case, there are a couple of dozen users per customer. We have about 2,000 active users per month, meaning that a huge user base is not the nature of our business. As a result, I can't really say anything about Auth0's scalability.

I do believe that they are prepared for a much larger scale than ours. That's the feeling I get from my experience with the platform.

When we faced problems with Cognito, we opened a ticket with Amazon and the response was horrible. Interacting with Amazon is really bad, especially if you have a problem and you need a fast response. And after a couple of tries, we moved to Auth0. 

With Auth0 you pay more than you do for Cognito, but you also get premium support. That means that you get a reply according to the severity of the ticket that you open, and that reply comes very quickly. Even for normal severity tickets that I have opened, I have always received a response on the same day. And generally, they have been very satisfactory responses. 

The only exception is when it comes to the features that we lack, but that is not something that support can help you with. That is more the type of topic you take to the product management team, and I respect that. I don't expect support to give me an answer or  a solution for everything.

We also have a quarterly talk with them where we can raise any issues or feature requests we have. The support we get from Auth0 is one of the reasons we went with them and one of the reasons that we stay with them.

Positive

We had developed something like this in-house some six years ago. Over time, we identified that it was a problem for us to chase the requirements and the changes needed to support more modern authentications, like SAML integrations, multifactor authentications, and other advanced security protocols. So we decided to try to find a vendor that would provide this for us.

The initial setup and deployment of Auth0 was pretty straightforward. But to be honest, we are only using 40 to 50 percent of the features they provide. And when we started, we were only using about 20 percent of the features, only the authentication part of it. Our use of it was fairly simple. 

We initially started down this path with Cognito from Amazon. We wrote the whole integration with Cognito and, about two months into that integration, we found a critical issue that we couldn't live with. We didn't get a decent answer from Amazon about it, so we decided to move on to another vendor.

Auth0, obviously, didn't have that issue. The bottom line is that it took us something like two or three weeks to migrate the whole thing from Cognito to Auth0. So in terms of the setup, that was pretty fast. Even migrating from an existing, competitive service, another IDP, was not that complicated. Again, it depends on how many of the features you are going to use. We decided not to go with features that couple us to the vendor so that we would not be locked in. That is what allowed us to migrate to Auth0 in two weeks.

We haven't calculated how much development we have saved by going with Auth0 and whether that justifies the cost of our three-year contract with them. My gut feeling is that it has been worth it, but it's on the edge. I would expect some more flexibility on the licensing, but all in all, I think it was worth it, not having to develop this in-house.

We haven't measured whether we have seen a decrease in customer support tickets due to fewer password issues, but my sense is that maybe there has been a small decrease because the flow is standardized. In addition, we are no longer responsible for sending emails when issues arise or for making sure the email server is up and running, et cetera.

Pricing of Auth0 is a pain point. Their pricing model is very confusing, at least for an enterprise. I don't like their pricing model. I think it's too aggressive. It's not very cheap for a service that only does authentication. There are some cheaper services, and we find the negotiations with them to be pretty tough.

One of the benefits of Auth0 is the SAML integration with SSO and other IDPs but it is priced very high. I would expect this ability to be included, because we pay them good money, and not priced the way it is priced today. This is one of the areas where we are not happy with Auth0.

We chose Auth0 after we did some research into other candidates. We looked into Cognito by Amazon because it was the cheapest.

We also looked at Okta, and although this might have changed in the last three years, at that time Okta didn't have a clear strategy to support a large volume of customers. It looked like they were more focused on enterprises and their pricing model did not work with the needs of a customer-facing authentication system. Today they have an offering for that, but three years ago it wasn't like that. 

We also looked at some on-premises solutions, like Shibboleth, but we didn't seriously consider them.

We could manage without Auth0 Rules. We built an architecture in which all the communication to and from Auth0 is centralized in a single service, within our company. We could add this business logic to our service and have the same functionality. But the fact that it's available for us in Auth0 means we don't need to change our code or our service to support it, and that makes things a little bit more convenient. On a scale of one to 10, the importance of Auth0 Rules for us would be a seven.

The biggest lesson I have learned from using Auth0 is that when a company does something very well, you are probably better off using their service instead of trying to do it yourself. Doing it on your own requires investing in the development and the maintenance of it. Also, things change over time and you have to keep up. The policy in our company is that whenever a company does something very well, and it is not our core business, and the price is reasonable, we might want to pay them to externalize that product or service.

We use the solution for B2C connection between our customers on the mobile web.

It is easily connected and easy to put our app in single sign-on. For example, Auth0 is easy to bring connections for mobile devices and has good documentation.

Today we use home basic authentication and authorization, and we would like to move away from cloud and use some kind of IDP to improve authentication and authorization for our customers. So, for example, we can use the social logging feature in Auth0 to improve the customer experience.

The price modelling is a bit confusing on the site and can be costly. So if you use one measure like active user format, you need to talk to the support from Auth0 to check the price.

We have been using this solution for about two months. We are using the latest version. It is currently deployed on private cloud.

It is stable according to the documentation and support we have from Auth0. I rate the stability a ten out of ten.

We have 50 users using Auth0 and plan to increase the number of customers.

I rate the technical support a ten out of ten. It is very good.

The initial setup was easy, and I rate it a ten out of ten. Our company uses Terraform to build up infrastructure from AWS, and we used a partner to build the product. We needed around five people for deployment, and they were mainly engineers and senior developers.

The pricing is very high, so I rate it a four out of ten. To be in auto-production, we need other add-ons and extras that can be used for motor factory authentication. So for our product, we need to have multifactor authentication and pay for it.

I rate this solution a ten out of ten. I recommend architects and engineers check and verify how many users they need for some time, like a month, six months or even a year. With this approach, you can check the price and costs from Auth0 support and try to balance the costs and features we would like to have.

Our initial use case was authentication. We didn't want to implement anything from scratch, so we needed an out-of-the-box solution. That's why we chose Auth0.

Right now, it's deployed on-premises for our development environment and on cloud. The cloud provider is AWS.

We're in the beginning stages of a project, so only 10 people are currently using this solution in my organization.

Currently, we're just using the login and sign-up features. The most valuable feature is interface application integration, but we haven't fully used it yet. We'll need it in the future for a few potential clients.

The Management API could be improved so it's easier to get user information.

I've been using Auth0 for three months.

The solution is stable.

I've had a few problems with the scalability, but it's okay overall.

Initial setup is easy. Deployment took less than an hour.

There are different price levels: B2B, B2C, and enterprise.

The basic plan is about $1,500 per month.

The basic plan is good for our requirements. In the future, we might get the enterprise plan.

I think Auth0 is worth the cost.

I would rate this solution as six out of ten. 

There are a few small problems, like with Management API. For integration purposes, it's easy to use. The solution is good for starting projects and for startups. There are a few other options for out-of-the-box solutions, like AWS or Azure AD, but we chose Auth0.

We were evaluating Auth0 as centralized authentication solution for our in-house development. We are searching for the best solution to take care of this because our product development is ongoing, and we want to find just the right fit. Ultimately, we did not choose Auth0.

The most valuable feature is that it is simple to integrate, irrespective of your codebase.

This is a costly solution and the price of it should be reduced.

We had been evaluating and testing Auth0 for between three and four months.

It is pretty much stable. We did not encounter any issues with respect to integration and testing.

Considering we are conducting a PoC, we are not able to fully test scalability. However, our understanding is that it scales well.

My team was in touch with their counterparts from marketing and technical resources, but because it was a PoC engagement, we did not take it further.

We did not use another SSO product before our current PoC began.

We have been evaluating multiple single sign-on solutions including Auth0 and Okta.

We run a successful proof of concept but we did not select Auth0 because their entire structure is hosted on AWS, and we are a data center company so we thought that having the backend hosted on AWS was not the right choice for us.

Had this same solution been available as a private deployment then it would have been the right fit for us.

During our exploration and evaluation, Auth0 and Okta were the top contenders from a pure authentication point. My advice for anybody who is considering such a system is to have multiple authentication systems evaluated from a technical point of view, and adopt the one which rightly suits your use case and requirements. Different products have different features sets, but what matters most is that it is purely compatible with your use case. Scalability is probably the most crucial factor.

I would rate this solution an eight out of ten.

I'm a security architect. The product is used by our customers, not by our company people directly, so I expect we would have several thousand people using this solution.

It has improved our organization by providing login authentication for a mobile app.

The most valuable feature would have to be authentication using OpenID Connect.

The product could use a more flexible administration structure in the next release. It could be improved by extending the administration model. 

There is no problem with product stability. 

We haven't had any problems with scalability. 

We've had good experience with technical support. 

We previously used a different solution which was an open-source solution that was on-prem. I can't recall the name of that, but it was an open-source tool. One of the main reasons we switched to Auth0 is that supporting an on-prem version required a certain amount of expertise and management and we didn't need to be spending money on that if we were using a software as a service provider.

The other aspect was that on-prem you have to manage the security yourself. By using a software product as a service provider in the cloud, we were able to outsource those security concerns to them. The security was their responsibility and no longer our problem.

The setup is straightforward. We've deployed it in a number of applications, some of those would have taken less than a couple of days of development and deployment, and some of them would have taken weeks. But it's dependent on the complexity of the deployment. That's not a function of Auth0, it's a function of what our digital transformation is trying to do. We used an Auth0 consultant for deployment. 

We used an Auth0 consultant for implementation and he was very good and very knowledgeable. There is nobody in our company dedicated to maintaining the system for our customers. 

There are licensing costs for this product. We have an enterprise agreement with Auth0.

We evaluated a couple of other options before choosing Auth0. We looked at Microsoft and Okta. We went with Auth0 because at the time Microsoft was about to renew, so it wasn't as easy to set up, although Microsoft is a fine product and Okta is also a fine product, at that stage, it was more aligned on-prem authentication than it was to B2C.

In terms of advice, I think that if your application is developer-driven, then Auth0 provides extremely good developer support and supports multiple development tools and strategies. That's where I believe the product comes into its own. If you're enterprise, then Okta or Microsoft are probably a better solution. It's worth watching.

I would rate this product an eight out of 10. 

The most valuable feature of the product is scalability. 

The tool's price should be improved. 

I have been using the product for three years. 

I would rate the solution a ten out of ten. 

The primary use case of this solution is to authenticate APIs, customer authentication, and business-to-business authentication.

The valuable features are that it is extremely secure and that it's developer-friendly.

In the past, there was an issue with the multi-tenant where there wasn't the ability to manage them. For example, if you have three tenants you couldn't have different managers, but that has been sorted out through the release tool.

I have been using Auth0 for three years.

This solution is stable, we have not had any issues.

It's a scalable product.

We have contacted technical support and find that they are good.

The initial setup of the solution was simple, but our requirements were complex.

The deployment time varied depending on the complexity. Some would have taken a week while others would have taken three months.

We used external consultants and consultants through Auth0 to help with the implementation.

This solution does what we want it to do. It's good and I don't see any issues.

For anyone wanting to use this solution, make sure that your developers are fully engaged. They have to know how Auth0 works and what the best way to leverage it.

I would rate this solution an eight out of ten.

I implemented the use of authentication workflow entirely on the client side (S.P.A./Single Page Application). This gives the client app a JWT and makes the infrastructure a lot easier to manage in a distributed way since I don't need to track user sessions on the servers anymore. Now, I simply use the JWT from the client on the server side to process requests and push updated profile data to a database/queue as needed and end the process without having to persist data in the web server (sessions).

We are now able to dockerize stateless containers quote easily. A typical solution for managing session data is to put it into a database, but now we don't need to do that either. Auth0 essentially acts as the database backend. However, unlike regular session management through a database, whereby one needs to touch the database every time to re-hydrate session data for every request, I only make requests to Auth0 to query for profile data when needed, thus making the application more efficient.

The documentation and getting started guide is excellent for JWT and client-side authentication. However, I think they can do a better job in explaining what you're supposed to do next in order to correctly follow an idiomatic approach to using the solution beyond simply passing a JWT token to a server and having the server check then signature to validate the token.

I've just started using it.

No issues encountered.

We used regular OAuth in conjunction with our own database for people without social accounts. This is much better because everything is wrapped and normalized through one service. It even supports non-OAuth solutions such as Active Directory and LDAP which is good.

It was extremely simple and their site even generates sample code in various languages.