Cognito Under the Hood

Have you ever implemented a user database and authentication layer yourself? There are many things to get right: Hashing and salting passwords, multi-factor authentication, brute force attacks, and many more. That’s why I recommend using a production-ready service instead of building authentication yourself. That’s what Amazon Cognito is all about.

Let me start with typical use cases for Cognito:

Serverless app with API Gateway

A typical Serverless application uses Cognito User Pools for authentication and authorization.

1. The client authenticates with the User Pool.
2. The client sends the identity or access token as a header to the API Gateway.
3. The API Gateway verifies the token and grants access.
4. The API Gateway adds information from the identity/access token to the context when invoking a Lambda function.

Obtain temporary AWS credentials

Cognito Identity Pool allows federated identities to access AWS resources by issuing temporary AWS access credentials. Users can use those credentials to interact with AWS APIs directly (e.g., AppSync, S3, DynamoDB, …). That allows clients to access data stores without a backend.

Cloud-native app with ALB

You can add authentication to any cloud-native app that sits behind an ALB. ALBs support authentication/authorization based on Cognito User Pools.

We use it to add a layer of security for traditional tools like Jenkins, phpMyAdmin, etc.
You can find a working example here: https://github.com/cfn-modules/docs/tree/master/examples/fargate-alb-auth-cognito

The following video covers:

• When to use AWS Cognito?
• Demo: ALB + Cognito User Pool
• User Pool vs. Identity Pool
• Pitfall: Backup your most valuable asset!

Summary

The following table helps you to decide which option to choose.