A Quick Cognito/Auth0 Overview
Role-Based Access Control
Who has not started a web or mobile application and needed an authentication and authorization service? One of the most important things you need to take into account when you build an application is security. Of course, clients want to have the guarantee that their data is secure enough. One of the best options to achieve this is definitely Role-Based Access Control (RBAC). As the name indicates, the idea behind RBAC is to grant permissions to users based on the role they play within an organization. In this post, we are going to make a quick overview of RBAC and explore some options such as Cognito and Auth0 to achieve our goal, which is to build a “Role-Based Access Control” layer for our application.
As mentioned above, RBAC refers to the idea of defining permissions for a user based on the role they play within an organization. This is a manageable approach to grant authorization inside your application and is less error-prone than assigning permissions individually. Imagine this scenario, your company has around 1000 employees and you need to assign permissions individually to each employee. Let’s say you have a rotation of employees, and you need to change permissions for a set of users according to the tasks they need to achieve…😢 I know, it’s a nightmare. Lucky us we know RBAC 😎.
When using RBAC, you analyze the needs of your organization/application and define groups, the users/employees inside each one of these groups share responsibilities/needs. Let’s say that our small app allows users to post content. In this scenario, we have a group of users that can read the post, and we have a set of users that can edit the post (for example an admin group that censures bad content before publishing in the site). Really simple to achieve if we use RBAC, we just need to define the two sets described above:
- Users/Employees who can read the post
- Users/Employees who can edit the post
Wait a minute…🧐, how a user can edit the post without reading it? Exactly, this is one of the advantages of RBAC: you can assign more than one role per user/employee. In this case, the users that can edit belong to both sets, in other words, the edit is a subset of the read set. We can then assign more permissions to the roles, and more roles to a user, and change this whenever we want for a set of users.
- Reduce admin work (simple to audit user privileges and catch identity issues).
- Highly maintainable (easy to add/change roles across the app).
- Reduces the error rates when assigning permissions to users.
- Improving Compliance.
- Easy to integrate with third-party users.
All the benefits described above are key for any company, even more for those companies that are part of the software world such as PaaS and SaaS. As we mentioned in the last section, it is very important that every user in our app feels that the information they provide us is secure, and to achieve that we need good authentication and authorization systems. Here is where services like Cognito or Auth0 play a key role 😁. Sure we can try to implement that by ourselves, but we could also reinvent the wheel 👀. Although there is no real benefit in doing that right? At least not for a young company.
Using services like the ones mentioned above helps us a lot. Those services have already been tested by a lot of people and pruned of errors. Meaning we’ll save time and improve our application for sure, so a win-win situation 😎.
Cognito and Auth0
Both services provide RBAC and are highly used/recommended around the web. In general, the feedback is similar, both are flexible for integrations, and save a lot of time by providing a good/secure way to implement authentication and authorization in your application.
- You built an API and you want to secure it with a proper authentication system.
- You have more than one app and you want to implement Single Sign-on (SSO).
- You built a great app and one requirement is to have 2FA by email or SMS.
- You have a bunch of microservices and you want to grant temporary access to a set of your internal services to some of your clients.
- You are interested in growing compliance requirements of SOC2, GDPR, PCI DSS, and others.
- You want a way to manage the users in your application: sign in, sign up, reset the password, activate/deactivate accounts, manage roles, and others.
The use cases described above are part of the functionalities that Cognito and Auth0 provide, both services are great options for RBAC.
Auth0 is a drop-in solution to add authentication and authorization services to an application. It is easy to integrate and does not depend on any language or stack, which means it can be integrated with any application and you can define the Identity Providers you need for your application. It also provides SDKs and you can configure hooks to your application. It provides an easy and scalable solution. It also provides functionalities like Security Assertion Markup Language (SAML), JWTs, OAuth1, OAuth2, and others.
A downside of Auth0 is it can be limiting, especially if you want a lot of control over the design of your authentication flow, which is understandable. A good friend of mine always said: “You can’t always get what you want” 🎶😉, guess what he is right. Another important downside is that Auth0 API documentation has proven confusing. An endpoint can change by adding/removing some parameters, and sometimes the values that you expect in a response can be absent or have unexpected values. Finally, Auth0 can be a little expensive 😢.
Amazon Cognito recently gained the attention of the serverless community because of the functionality and flexibility that it provides for securing serverless applications. Cognito provides fully managed authentication and authorization services, it is highly scalable and effective 🤩, but nothing is perfect, right? Cognito has a downside, and that is the learning curve. Even if it looks intuitive it can be tricky to understand all the features that it provides, but without a doubt, it is a powerful tool and we can take advantage of it 😉.
One of the main reasons why Cognito can be tricky at the very beginning is the documentation. You can run into confusion. I know this happens with some of the AWS services, but AWS is a powerful PaaS and even if at the beginning it is a little tricky, in the long run, it can save you time and make your life easier 😁.
Cognito provides two main services:
- User Pools
- User pools is a scalable solution for authentication and authorization management, and it provides an easy way to manage your users.
- Allows you to build and manage groups/roles, which is the idea behind RBAC.
- Federated Identities
- Provides a solution to grant temporary access to AWS resources using IAM roles.
The main difference between these two services is that Users Pools don’t manage IAM roles at any point but you can use it together. The documentation is not entirely clear, but yes all you need to create a federated identity is a user pool. The examples in the documentation abroad identities like Facebook, Twitter, Google, and others but indeed you can use your Cognito users pools like identities, which is a powerful tool if you are in the serverless world.
Certainly, both Cognito and Auth0 are very powerful and depend on your use case. For example, if your stack is structured in AWS; certainly Cognito can be the best fit, due to fast integration and compliance (all your services are under the same roof 🏡), even more, if you use a serverless approach, you can take a lot of advantage of Federated Identities, Auth0, on the other hand, provides a fast integration if you only want to add OAuth 2.0 to you newly branded application 😁. So as I said before, it depends on your needs and stack, but you should avoid the impulse to create all this by yourself. Especially if your company is growing 🙌🚀.