Authentication and Authorization

When I started working as a web developer 10 years ago, my very first assignment was to implement user login for a system, then the second assignment was to implement a permission control system. Later on, I learned those were called authentication and authorization, respectively.

Authentication and authorization have different meanings in a strict context. Authentication (Authn) means “are you the person you say who you are”, it checks password, or checks if a token is legitimate. Authorization (Authz) means “OK, I have recognized you’re the person you say who you are. Can you do action X on resource Y with this identity?” Authorization usually involves which user has which permissions, and often involve the concept of “roles”, and an RBAC(Role-Based Access Control) system.

When I started working on Flux, I knew startups these days are often built upon all kinds of services. One of the first services I want to “outsource” is Authn and Authz systems, partially because I don’t want to write the whole auth system again, also because auth systems have been implemented so many times so I expect a good abstract, not as a library but as a service.

I evaluated a few options and chose Auth0. Reasons:

• It’s a startup, too. Authentication service is their whole business, not a toy project that could die when “business priority shifts”. It’s also a relatively established startup that should last.
• It seems mature enough and some big-name companies use it. Comprehensive API and client libraries. Lots of nice documents.
• It uses JWT (JSON Web Token) and has been a leader of defining this standard. JWT has been very popular in a service-oriented architecture that authentication needs to happen in a distributed way (not via a central authentication server).

That being said, it wasn’t all smooth sailing when implementing Auth0. The learning curve is still somewhat steep, maybe because some of the complexity it introduces is not required for a simple system. And there is some messiness to deal with, due to outdated documents, holes in product design, etc. But overall I have been happy with Auth0. We could probably spend a similar amount of engineering effort to roll our own authentication system, but there are just too many ways to go wrong in a complex field like this. And the cost of going wrong in authentication could be very high. I feel after we spend an adequate amount of effort on top of Auth0, we can get to an 80/100 level, instead of 60/100 if we rolled our own.

Note we only used Auth0 for Authentication. Authorization handling in Auth0 was done by an extension, which felt like a second-class citizen. Recently Auth0 rolled out an RBAC Authorization function to replace the extension, which I think was a good move but came a little late for us. For Authorization, the best and the most comprehensive system I’ve used is probably AWS IAM, so we utilized a library that uses a similar fashion to define roles and permissions in statements like “Role A can do action B on resource C on condition D”. The implementation based on this library was pretty concise and we have been happy about it.

A worth-noting point of an authentication service like Auth0 is it only handles authentication, not user management. We still have a user table in our database, and some linking/synchronizing logic needs to be built to connect the Auth0 service into our system. We just don’t need to store or directly handle users’ password anymore, which seems not that a big deal but think how many big tech companies had leaked users’ passwords (sometimes plain text!) in recent years.

Overall, I’d recommend startups to consider using an authentication service. It helps get things done right, and it’s crucial to get authentication done right from day one. The expectation of using such service also should be right: you still need to spend efforts to integrate, you still need to manage other aspects of your users, and most importantly, you still need to have proper security knowledge and understand how authentication/authorization work. At the end of the day, you are responsible for the security of your system, no matter what services and tools you use.