Learn how to implement identity management for your serverless apps using Amazon Cognito User Pools, Amazon Cognito Federated identities, Amazon API Gateway, AWS Lambda, and AWS Identity and Access Management (IAM).

Sign-up and sign-in. How do you store credentials? Never store passwords in plaintext. It is vulnerable to rogue employees. A hacked DB can result in all the stored passwords being compromised. The use of hashed passwords does not solve problem because of MD5/SHA1 collisions, the use of Rainbow tables (for reversing cryptographic hash functions, usually used for cracking password hashes), and dictionary and brute-force attacks (GPUs are capable of computing billions of hashes/second). A better approach is to salt hash these passwords by incorporate app-specific salt and random user-specific salt or use algorithm with a configurable number of iterations to slow down brute-force attacks. But what if you did not want to transfer the password over the wire or even save it in the database. In such cases you can use Secure Remote Password (SRP) protocol or Verifier-based protocol. Using these protocols ensures that passwords never have to travel over the wire and they are resistant to several attack vectors. They ensure Perfect Forward Secrecy (PFS) property for secure communications in which compromises of long-term keys do not compromise past session keys

So now you have taken care of Secure Password handling requirement; what about other requirements such as multifactor authentication, enforcing password policies, and encrypting all data server-side. On top of it, what about user flows such as registration, verification of email/phone number, secure sign-in, forgot password, change password, and sign-out functionality. Thankfully, there is an AWS service for it—Amazon Cognito. More specifically, Amazon Cognito User Pools (managed user directory).

A typical set of steps from a mobile app to Amazon Cognito User Pools include the following:

1. A register request is sent from the mobile app
2. A verification SMS/email is sent by Cognito
3. The user confirms the registration
4. Cognito responds with a successful registration message
5. An authenticate (via SRP) request is sent from the mobile app
6. Cognito returns the requisite JWT token (JSON Web tokens)

An alternate flow after successful registration is also possible if you want to implement CAPTCHA or MFA for Authentication (via SRP). You can define a custom authentication challenge. You can hook in a lambda function into the flow. Here, the steps after a successful registration will include the following:

1. An authenticate (via SRP) request is sent from the mobile app
2. A custom challenge (CAPTCHA, Custom 2FA) is presented by Cognito

3. A challenge response is sent by the mobile app (with a Lambda function triggered to verify the authentication challenge response)
4. Cognito returns the requisite JWT token

In fact, you can hook in Lambda triggers at each of the preceding steps, as required.

The JWT token consists of a header, payload, and a signature (all three together as a Base64 encoded blob of text makes up a JWT token).

You get three types of tokens from Cognito, which are as follows:

• Access token: This provides access or programmatic API interactions.
• Identity token: This can be used for downstream pseudo-authentication. You can use this token to dynamically change the experience of the user by just reading the token.
• Refresh token: This token is required because the Access and Identity tokens from Cognito are only good for one hour when issued. But a refresh token can be valid for as long as 30 days. You can use the refresh token to get a new access or identity token.

With Cognito User Pools, a user will be able to register, sign-in, and sign-out. Now, if the user needs to access AWS resources, for example, each user has a profile and they want their profile picture. We want to take advantage of Amazon S3 for that. To give them secure fine-grained access to S3, we need Amazon Cognito Federated Identities. This service allows you to exchange tokens from User Pools for AWS native credentials for federating access to AWS resources. Amazon Cognito Federated Identities calls AWS Security Token Service (STS), which is essentially a cloud-based token vending machine.

Prior to December 2016, Amazon Cognito Federated Identities had unauthenticated and authenticated user roles. Now, for fine-grained, role-based access control, you have two more features for authenticated users Choose a role from rule and Choose a role from token. Using the Cognito groups feature (for Choose role from token), you can specify an IAM role for each group and the users of that group will have the associated permissions. Note that a user can have only one IAM role active at a time.

You’ve set up the basics. Now, let's look at authorization requirements of your serverless application. If your application uses API Gateway, Lambda, and DynamoDB, then you can actually offload all of your authorization requirements to the API Gateway.

API Gateway supports three types of authorizations, which are as follows:

• Amazon Cognito User Pools using User Pools Authorizers. (We cannot differentiate admin user from other users; hence, we will need more fine-grained authorization.)
• Amazon Cognito Federated Identities using AWS IAM authorization. This is the most common option used by most businesses. It provides fine-grained access control.
• Custom Identity Providers using Custom Authorizers.