Chapter 6

Chapter 6. Managing identities

This chapter covers

• Introducing the identity features provided by Amazon Cognito
• Using external authentications already integrated with Amazon Cognito
• Integrating your own custom authentication
• Managing authenticated and unauthenticated identities in your application

configuring the required permissions for those functions to act on other AWS resources such as
S3 buckets or DynamoDB

manage authentication for external users interacting with AWS resources and Lambda functions
via a client application

Amazon Cognito has been designed specifically to make it simple for external users and applications
to assume a role on AWS and get temporary security credentials.

6.1. Introducing Amazon Cognito Identity

Amazon Cognito could be used to provide AWS credentials to the client, so that the client application
could directly invoke AWS Lambda functions.

protect access to the web API exposed by Amazon API Gateway (figure 6.3). To do that,
in the API Gateway web console you can choose the AWS IAM authorization type in the
Authorization Settings of the Method Request.

trust an external authentication: a standard one, such as Facebook

Cognito gives a unique Identity ID that follows users across any device they use. For unauthenticated
users, Cognito gives a guest Identity ID that will stick with the device

Cognito supports two kinds of identities, unauthenticated and authenticated, each with a different
IAM role that can be assumed using the returned (temporary) credentials

AWS account can manage multiple applications, Cognito allows you to create different pools of
identities that have no dependencies with each other

interaction works between the client, Amazon Cognito, the external (or custom) authentication service,
and other AWS services

1.  The user is using a client application, such as a mobile device or a JavaScript application running
in a browser.

2.  The client application sends the identity pool ID to Amazon Cognito to get an Identity ID.

3.  If the identity pool is configured to allow unauthenticated users, the client application receives a
guest Identity ID for the unauthenticated user that will be stored locally on the device (smartphone,
tablet, web browser) and will be reused in future connections by the same client application.
The client application can also get temporary AWS credentials to assume the unauthenticated role of
this identity pool.

4.  The client application can directly use other AWS services authenticating with the temporary AWS
credentials it has received from Amazon Cognito, which allow access to the actions and the resources
specified in the policies attached to the unauthenticated role of the identity pool.

Figure 6.4. Cognito Identity usage flow for unauthenticated users

unauthenticated users limited read-only access to AWS resources used by your application.

give access only to those AWS Lambda functions that aren’t making important changes. As a result,
unauthenticated users can only visualize what authenticated users are doing.

6.2. External identity providers

authenticated users, you need a place to authenticate to

use an external authentication, such as Facebook

burden of managing the authentication from the developers and simplifies the user experience

• Amazon
• Facebook
• Twitter
• Digits
• Google
• Any OpenID Connect–compatible provider, such as Salesforce

Cognito trusts the authentication from the external provider using the authentication token received by
the client to validate the authentication.

1.  The user uses a client application, such as a mobile device or a JavaScript application running in a
browser.

2.  The client application authenticates with the external identity provider, usually using the provider
SDK, sending the identity provider credentials (not related to AWS in any way).

3.  If authentication is successful, the client application receives an authentication token from the
identity provider.

4.  The client application sends the identity pool ID and the authentication token to Amazon Cognito
to get an Identity ID.

5.  Amazon Cognito checks the validity of the authentication token with the identity provider.

6.  If the authentication token is valid, the client application receives a unique Identity ID for the
authenticated user that will follow across any device (smartphone, tablet, web browser) where the
same authentication is used. The client application can also get temporary AWS credentials to assume
the authenticated role of this identity pool.

7.  The client application can directly use other AWS services authenticating with the temporary AWS
credentials it has received from Amazon Cognito, which allow access to the actions and the resources
specified in the policies attached to the authenticated role of the identity pool.

authenticated users write access to AWS resources used by your application, directly or via AWS
Lambda functions, so that they can upload files or change data on a database.

only information required by the client application is still the identity pool ID; no AWS credentials
are embedded in the application

6.3. Integrating custom authentications

Amazon Cognito can use any custom authentication service.

service has to do a back-end call to Amazon Cognito to ask for an authentication token

developer authenticated identities.

1.  The user uses a client application, such as a mobile device or a JavaScript application running in a
browser.

2.  The client application authenticates with the custom identity provider, usually using the provider
SDK, sending the identity provider credentials (not related to AWS in any way).

3.  If authentication is successful, the custom authentication service does a back-end call to Amazon
Cognito to get a token for the developer identity (the actual API call is
GetOpenIdTokenForDeveloperIdentity).

4.  The client application receives the authentication token returned by Cognito from the custom
authentication service.

5.  The client application sends the identity pool ID and the authentication token to Amazon Cognito
to get an Identity ID.

6.  If the authentication token (originally generated by Cognito) is valid, the client application
receives a unique Identity ID for the authenticated user that will follow across any
device (smartphone, tablet, web browser) where the same authentication is used.
The client application can also get temporary AWS credentials to assume the authenticated role used
by this identity pool.

7.  The client application can directly use other AWS services, authenticating with the temporary AWS
credentials it has received from Amazon Cognito, which allow access to the actions and the resources
specified in the policies attached to the authenticated role of the identity pool.

6.4. Having authenticated and unauthenticated users

have only authenticated users Have both unauthenticated and authenticated users

No authentication is necessary for the purpose of the application, but you can still use Cognito and get
an Identity ID for the users to get usage analytics and understand how they use the application

Authentication is optional; unauthenticated users have access to a limited subset of features and
are naturally brought to authenticate to gain access to more advanced functionalities.

Authentication is mandatory and is the first step when a user is starting to use your application.

Forced authentication isn’t the best way for a user to experience a new application. It can slow
adoption unless your application is clearly targeting a private environment

Having no authentication limits the ability to customize the user experience and to follow
the same user across different devices.

6.5. Using policy variables with Amazon Cognito

specific policy variables that you can use to build more advanced policies

Access to private folders on Amazon S3 (listing 6.1), where only a specific user can either read

• or write. This is useful for holding private data.
• Access to public folders on Amazon S3 (listing 6.2), where a specific user can write only in
• their own folder, but all folders can be read by all users. This is useful for holding shared data.

Listing 6.1. Policy to give access to private folders on Amazon S3

private access to Amazon DynamoDB (listing 6.3), where a user can only read or write items in a table if their own Identity ID is in the hash key Shared access to Amazon DynamoDB (listing 6.4), where a user can only write items
if their own Identity ID is in the hash key, but users can read all records in the table

can give secure access to a file store and a database straight from the client application

subscribe a Lambda function to changes in the file store or the database.

subscribe a function to Amazon S3 and check the validity of any file that’s uploaded. If you’re
expecting users to upload pictures, then you can check that the uploaded files are pictures with the
format and size you need.

Identity ID is bound to a single device and can change if the app is removed and downloaded
again or the cache of the web browser is cleared. I suggest using those policies only for an
authenticated role.

trust relationship to allow Amazon Cognito to let external users or applications assume the role.
The trust policies you use must distinguish between authenticated and unauthenticated users;
otherwise, unauthenticated users could assume the authenticated roles.