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:
A typical Serverless application uses Cognito User Pools for authentication and authorization.
- The client authenticates with the User Pool.
- The client sends the identity or access token as a header to the API Gateway.
- The API Gateway verifies the token and grants access.
- The API Gateway adds information from the identity/access token to the context when invoking a Lambda function.
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.
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!
The following table helps you to decide which option to choose.
|User Pool||Identity Pool|
|Built-in User Database||✅ Yes||❌ No|
|Grant access to AWS resources directly||✅ Yes in combination with an Identity Pool||✅ Yes|
|Social Login||Google, Facebook, Amazon, Apple||Google, Facebook, Amazon, Apple|
|SAML||✅ Yes||✅ Yes|
|OpenID Connect||✅ Yes||✅ Yes|
|Hosted UI||✅ Yes||❌ No|
|Costs||$0.0055 per Monthly Active User (MAU)||Free|