AWS Cognito User Pools or Identity Pools: what do I use to secure my API?

14,820 reads

@ davidgf David García Passionate about #RubyOnRails, #NodeJS, #Javascript and #Serverless @da_vidgf

As a developer, you don’t like reinventing the wheel. You need to add authentication and authorization to your API and you’ve decided to use a third-party service, instead of rolling your own users management system. You are familiar with AWS, so Cognito is the way to go. You check the docs and try to understand what is User Pools, what is Identity Pools and what is the difference between them.

That’s your face when going through Cognito docs

No worries, we’ve all been there. It’s really confusing, specially if you’re not an expert on authentication and authorization protocols (I include myself there). Both services seem to be built for the same purpose, so choosing one or another can become a tough task.

Long story short

If you’d like to access AWS resources directly from the client side (be it a mobile or a web app), use Cognito Identity Pools (CID). Go for User Pools (CUP) otherwise.

I trust you, but what’s the deal?

Even though User Pools and Identity Pools seem to be similar, there are some aspects that make them quite different. First, we should pay attention at what the outcome of the authorization process is in both cases. User Pools provides us with a JSON Web Token, so we can use it as an authorizer for any existing API, while with Identity Pools we get temporary AWS credentials, which means that is meant to utilize AWS resources. We can definitely use it as an API authorizer, but only if it’s exposed through AWS API Gateway.

Taking note of what is the type of credentials delivered by CUP and CIP made me realize which use cases each service is suited for, although there are more features that could make you lean on one or another. With CUP you get the whole users management system, you’ll be able to let your users sign up with their email and password (and additional attributes if you like), or through another identity provider, such as Facebook or Google. You can also include additional security measures, like Multi-Factor Authentication, or have a customized sign up flow, by verifying users’ emails or mobile phone numbers. On the other hand, CID doesn’t count with an users directory, it fully relies on trusted third-party identity providers for authentication . Some other feature supported by CUP is OAuth2 compliance and support of scopes, which would allow third-party applications access your users’ accounts on their behalf and open up your secure API to the Internet.

In brief, you could follow the flowchart below to help you choose the service you want based on your needs:

Cognito User Pools or Identity Pools depending on your needs

Common use cases

You can see below some common scenarios where you could be hesitating about which service suits your needs:

I’d like to access AWS services directly from my mobile app: if what you’re aiming for is using AWS as sort of a Backend as as service , you should use CID . By getting AWS credentials, you could query DynamoDB tables directly from the client or publishing an SNS notification, for example, straight away from the client side. If you are building a JavaScript app, it’s worth taking a look at the AWS Amplify library.

if what you’re aiming for is using AWS as sort of a , you should use . By getting AWS credentials, you could query DynamoDB tables directly from the client or publishing an SNS notification, for example, straight away from the client side. If you are building a JavaScript app, it’s worth taking a look at the library. I’d like to secure an API not exposed by API Gateway: in this case, CUP is the way to go. It relies on the JSON Web Token technology, so you can pretty much decode and verify the signature of the token from any web application.

in this case, is the way to go. It relies on the JSON Web Token technology, so you can pretty much decode and verify the signature of the token from any web application. I’d like to give access to my users’ data to another applications: again, CUP is the winner here. It’s OAuth2 compliant and let’s you define custom scopes.

again, CUP is the winner here. It’s OAuth2 compliant and let’s you define custom scopes. I’d like to add fine-grained permissions based on user types in API Gateway: in this scenario you could pick any of them. With CID you basically have to define a IAM Role to set the users’ permissions, which can be as granular as you want. On the other hand, with CUP, the built-in API Gateway authorizer only checks if the provided token is valid, but you can always create a custom one and define the permissions you need in combination with CUP Groups.

Conclusion

Cognito is a confusing AWS service and, let’s be honest, its documentation doesn’t help. However, as soon as you get your head around the fundamentals of its variations, the choice between them becomes easier. I hope this article helped you to understand them better!

Tags