You’re considering using an auth product like Auth0, Okta, Firebase, or Cognito and want to pick something that fits your situation best. You start searching for alternatives and are quickly swamped by conflicting sources of information. I know this pain. Let me help you a little.
When looking for solutions in the auth space, your main obstacle will be the conflation of terminology. Products with entirely different functionality are marketed using the same words. More words means more search keywords, which may be great for SEO, but doesn’t help us poor users.
Let me give you an example. A solution that helps reduce login friction for your users looks completely different than a solution to restrict your app functionality based on user roles. You may care about one and not the other. Yet, products that are strong in the latter are described almost the same as ones that mainly deal with the former.
It doesn’t help that most product websites suck. They suck because they’re made by marketing people for not-so-technical decision makers. Try to explain the difference between authentication and authorization to a marketing person… They sound similar, so must be the same, right?
Then there are all those comparison sites listing SaaS products and their competitors. They may give you some ideas on who the players are in the space but fundamentally suffer from the same problem - they lump different things together. This problem becomes immediately obvious when you see LastPass in the same list as Auth0.
Let me tease all these apart and show you the most important categories in the space, so that you’re better equipped to do your own comparisons. My goal is to give you vocabulary to go out and search for solutions that meet your criteria and a decent starting point in terms of existing products.
Main keyword: authentication.
You’re not an expert in security and don’t want to deal with the complexities of sensitive data storage, multi factor authentication, or preventing data leaks.
There are two crucial things here: security and reliability. Duh, but what does that mean? Forget about all those shiny certification badges you see on websites - they don’t mean anything. You want to look at reviews, perhaps talk to the sellers to see how they approach it. Look at their SLAs and if they have a website showing their current service status.
Main keyword: single sign on (SSO).
Your users may login using different mechanisms: their company’s active directory, common federated login providers, their social media account. You want to allow them access regardless of what login provider they use, and don’t want to write separate code that handles all these providers.
This is an area that can get very expensive quickly. Scrutinize the pricing and see what’s actually offered. See how easy it is to set up a new connection - some solutions out there boast they integrate with X in their marketing materials, but then you find out you have to pretty much write all the code yourself to handle the connection. Also pay attention to the authentication standard used in each integration. Sometimes, identity providers support higher security standards than the aggregator uses to connect. You want PKCE and not implicit flow authentication here.
This is an area where you can find the most products. Many solutions are good, but the devil is in the details. Are you trying to create a single entry point for your internal corporate users, or are you writing an app that should integrate with different login sources? Some products can do only one, others do both.
SSO for enterprise employees:
SSO for the users of your app or B2B solution:
Main keyword: authorization.
You have shared resources in your application or different groups of your users can perform different actions. You want your user’s data to remain secure without adding friction for shared resources.
You want granular permissions for access control, otherwise you’ll find yourself hacking workarounds into the system. Consider how many hoops you’ll need to jump through to change the assigned permissions or roles. Ideally, you want a nice administration dashboard that gives you an overview of what’s going on and lets you configure business-relevant parts without calling your development team. Also needs to support fetching permissions outside of user tokens.
This is an area where you won’t find many ready to use solutions. Some of the authentication providers do a bit of authorization, but it’s usually clunky.
Main keyword: machine to machine authentication.
Your various services, clients, and other parts of your software need to act on behalf of your users or simply communicate with each other on the public internet. You don’t want to expose yourself to security breaches.
For some reason, this is an area where pricing differs dramatically between different providers. You may be tempted to think that more expensive solutions offer better functionality, but that’s not the case here. Why? Who knows. Pay attention how many machine to machine tokens are offered for what price, and how easy it will be to scale that number. Publicly verifiable tokens are a must.
You wish it existed, don’t you? You want one provider to solve all your auth needs - current and future. One vendor to deal with, so you don’t need to make dozens of decisions and deal with your software purchasing process more than necessary. One solution to rule them all.
I have bad news for you. It doesn’t really exist in the auth space, at least not yet. There really isn’t any single product that fulfills all your auth-related needs. Some vendors, such as Auth0 or Authress are trying to get there, but neither are truly comprehensive at this point.
Rather than looking for a one stop shop, I’m afraid you’ll have to consider what’s most important for you and pick a product that checks the most boxes, possibly augmenting it with another one. There really isn’t any other way.
Besides functionality, there are other factors to consider when picking an auth solution provider. Take these into account once you’ve picked a few providers that offer all the features you want.
How easy is it to start using the solution? Do you have to rewrite all your existing logic to do that? How strong is the vendor lock in once you start using the product - will you be able to change solutions without a massive headache in the future? It may not be easy to answer these questions without some serious digging. Good documentation, or better yet - API endpoints to play with, can give you a sense of how much effort could be involved in the migration.
How good is the documentation? Is it easy to access? Will your engineers understand it or will you have to contact support with every little question? How accessible is the documentation? Are there product usage related questions + answers on Stack Overflow or similar platforms? How good are the answers? If you contact support, will you talk to an engineer or a salesperson? These topics aren’t always the first priority when you’re looking for a product, but they’re well worth considering. Your engineers will thank you for that.
For SaaS products running on the web, are their SLAs published anywhere? How good are they? Do they fit your use case (it makes no sense to pay for 99.9% uptime if your users only log in once a week)? If you’ve decided for a self-hosted or self-managed solution, it means your team is on the hook for reliability and uptime of the service. How good of an SLA can they provide? Will you need them to debug and fix server problems in the middle of night or on the weekend?
Some products list pricing on their websites. Others require you to go through a salesperson to even begin estimating your overall cost. When talking about self-hosted solutions, you have to add the cost of maintenance by your own staff on top of any licensing fees. All of it makes it harder to compare different offerings. From my experience, if the price is not listed on the website, you’ll most likely end up paying more than you need to, unless you have access to a skilled negotiator used to playing this game with vendors. Also from my experience, self-hosted solutions seem cheaper at first, but end up more expensive in the long run. People tend to discount the amount of effort that goes into running a server smoothly, but it’s a real cost that adds up over time.