Introduction
Amazon Cognito is a managed identity service that adds sign-up, sign-in, and access control to web and mobile applications. Authentication is the process of confirming who a user is. Authorization is the process of deciding what that user is permitted to do. This guide explains what Cognito is, the problem it was created to solve, how it operates, and the situations in which it is appropriate.
What is it?
Cognito is composed of two main parts. A user pool is a user directory that manages registration and sign-in and issues tokens that prove a user has signed in. A token is a signed piece of data that represents a fact, such as a completed sign-in. An identity pool, also called a federated identity pool, exchanges a proven identity for temporary AWS credentials so that an application can access AWS services directly. The two parts are often used together, and each can also be used on its own.
Why does it exist?
Building authentication correctly is difficult and carries significant risk. Passwords must be stored securely, tokens must be issued and validated, multi-factor authentication must be supported, and sign-in through external providers must be handled. Mistakes in any of these areas can expose user accounts. Cognito was created so that these responsibilities are handled by a managed service that follows established security standards, which removes the need for each application to build authentication from the beginning.
How it works
A user registers and signs in to a user pool, either through a hosted sign-in page that Cognito provides or through the application using a software development kit. When sign-in succeeds, the user pool issues three tokens. The ID token describes the user, the access token grants access to protected resources, and the refresh token is used to obtain new tokens without signing in again. The ID and access tokens are JSON Web Tokens, a standard format that is covered in the guide on JWT tokens.
If direct access to AWS services is required, the proven identity is passed to an identity pool, which returns temporary AWS credentials that are limited by a permission policy. Sign-in can also be delegated to an external identity provider, which is a service that authenticates users, a process known as federation.
Architecture diagram
Advantages
- Managed security. Password storage, token issuance, and validation are handled by AWS.
- Standards-based. OAuth 2.0, OpenID Connect, and SAML are supported.
- Multi-factor authentication. A second proof of identity can be required.
- Federation. Sign-in through Google, Apple, and corporate providers is supported.
- AWS integration. Temporary credentials for AWS services can be issued.
Disadvantages
- Configuration complexity. The distinction between user pools and identity pools, and the many settings, can be confusing at first.
- Customization limits. The hosted sign-in page and some flows offer limited customization.
- Quotas. Certain limits apply and must be considered for large applications.
- Learning curve. The token model and the security concepts must be understood.
Common use cases
- Sign-up and sign-in for web and mobile applications.
- Protecting an API so that only authenticated callers are admitted.
- Allowing users to sign in with an existing social or corporate account.
- Granting an application temporary, limited access to AWS services on behalf of a user.
Best practices
- Multi-factor authentication should be enabled for accounts that require stronger protection.
- Token lifetimes should be kept short, and refresh tokens should be handled carefully.
- Tokens should always be validated by the service that receives them before access is granted.
- Permissions granted through an identity pool should follow the principle of least privilege, which is the practice of granting only the permissions that are strictly required.
Common mistakes
- User pools and identity pools are confused, so the wrong component is used for a task.
- Tokens are accepted without being validated, which allows forged or expired tokens to be used.
- Tokens are stored insecurely on the client, where they can be stolen.
- Overly broad permissions are granted through an identity pool.
Related AWS services
- Amazon API Gateway uses Cognito to authenticate the callers of an API.
- AWS Lambda runs the logic behind an authenticated API.
- AWS Identity and Access Management, known as IAM, defines the permissions that an identity pool grants.
Frequently Asked Questions
- What is the difference between a user pool and an identity pool?
- A user pool manages sign-up and sign-in and issues tokens that prove who a user is. An identity pool exchanges a proven identity for temporary AWS credentials so that the application can access AWS services directly.
- What tokens does Cognito issue?
- A user pool issues an ID token that describes the user, an access token that grants access to protected resources, and a refresh token used to obtain new tokens without signing in again. The ID and access tokens are JSON Web Tokens.
- Does Cognito support multi-factor authentication?
- Yes. A second proof of identity can be required through a one-time code sent by text message or generated by an authenticator application.
- Can users sign in with Google or another provider?
- Yes. Cognito supports federation, which allows sign-in through an external provider such as Google, Apple, or a corporate provider that uses SAML or OpenID Connect.
- Is Amazon Cognito free?
- Cognito provides a free tier for a number of monthly active users, after which charges apply based on the number of active users and on some advanced features.
This article is the summary. The book is the full, continuously updated reference: user pools, identity pools, Lambda triggers, tokens, federation, and real-world website integration.
View the book