Amazon Cognito FAQs

For first-factor authenticators, Amazon Cognito supports username/password, email OTP passwordless, SMS OTP passwordless, and WebAuthn passkeys. Cognito supports the following multi-factor authenticators (MFA): email OTP, SMS OTP, and TOTP authenticators. In addition, customers and partners can implement support for third party products and bespoke authenticators with custom authentication flows, using AWS Lambda extensions.

Yes, you can easily and securely add sign-up and sign-in functionality to your apps with Amazon Cognito. Your users can sign-up and sign-in using email, phone number, or user name. You can also implement enhanced security features, such as email verification, phone number verification, and multi-factor authentication. Cognito enables you to customize workflows by, for example, adding application-specific logic to user registration for fraud detection and user validation through AWS Lambda. To learn more, visit our docs.

A user pool is a tenant-based user directory that you can configure for your web and mobile apps. A user pool securely stores your users’ profile attributes and supports a custom schema. You can create and manage a user pool using the AWS console, AWS CLI, or AWS SDK.

Developers can use either standard OpenID Connect-based user profile attributes (such as user name, phone number, address, time zone, etc.) or customize to add app-specific user attributes.

Yes, you can use the aliasing feature to enable your users to sign up or sign in with an email address and a password or a phone number and a password.

To learn more, visit our docs.

Yes, you can set up password policies, such as length of password, character complexity, and password history requirements when setting up or configuring your user pool. In addition, Amazon Cognito supports compromised credentials checking on every user sign-up, sign-in, and password change to ensure that users are not logging in with a password that has been compromised at another site.

Yes, with Amazon Cognito you can require your users’ email addresses and phone numbers to be verified prior to providing them access to your application. During sign-up, a verification code will be sent to the user’s phone number or email address, and the user must input the verification code to complete sign-up and become confirmed.

Yes, you can customize sign-up and sign-in flows using AWS Lambda. For example, you can create AWS Lambda functions to identify fraud or perform additional validations on user data. You are able to trigger custom Lambda functions at pre-registration, post-confirmation (registration), pre-authentication, during authentication, and at post-authentication. You can also use Lambda functions to customize messages sent as part of email or phone number verification and multi-factor authentication.

Yes, you can opt to remember devices used to access your application, and you associate these remembered devices with your application's users in a Cognito user pool. You can also opt to use remembered devices to suppress second factor challenges (adaptive authentication) for your users when you have set up multi-factor authentication.

There are two ways you can migrate users from your application's existing user directory or database to user pools: just-in-time (JIT) migration and bulk migration.

Amazon Cognito helps you migrate users just-in-time as they sign in to your application using a built-in AWS Lambda trigger. The Lambda trigger enables you to migrate users’ data from an external system without forcing them to reset their password.

Alternatively, you can migrate users in bulk by uploading a CSV file containing the profile data for all your application users. You can upload the CSV file through the Amazon Cognito console, the APIs, or AWS CLI. Upon signing in for the first time, users must verify their account and create a new password using a verification code sent to their email address or phone number.

To learn more, see Importing Users Into user pools.

Yes, Cognito identity pools enables you to authenticate users through an external identity provider and provides temporary security credentials to access your app’s backend resources in AWS or any service behind Amazon API Gateway. Amazon Cognito works with external identity providers that support SAML or OpenID Connect, social identity providers (such as Facebook, Twitter, Amazon) and you can also integrate your own identity provider.

You can use Amazon, Facebook, Twitter, sign in with Apple, Google social identity providers, OpenID Connect (OIDC) identity providers, SAML identity providers, Amazon Cognito user pools, and custom developer providers.

Identity pools enable you to create unique identities for your users and securely federate them with AWS service providers. Customers leverage Amazon Cognito identity pools as a credential broker to obtain temporary, limited privilege AWS credentials to access AWS resources.

Users can login via Amazon Cognito user pools, OIDC identity providers, SAML identity providers, or social identity providers and gain role-based access to AWS services, such as Amazon S3 buckets or Amazon DynamoDB records. Identity Pools do not store any user profiles. An identity pool can be associated with one or many apps. If you use two different identity pools for two apps then the same end user will have a different unique identifier in each Identity Pool.

Your mobile app authenticates with an Identity Provider (IdP) using the provider’s SDK. Once the end user is authenticated with the IdP, the OpenID Connect token or the SAML assertion returned from the IdP is passed by your app to the Cognito identity pool, which returns a new Cognito ID for the user and a set of temporary, limited-privilege AWS credentials.

Cognito identity pools can integrate with your existing authentication system. With a simple API call you can retrieve a Cognito ID for your end users based on your own unique identifier for your users. Once you have retrieved the Cognito ID and OpenID Token, you can use the Cognito identity pools client SDK to access AWS resources and synchronize user data.

Cognito identity pools assigns your users a set of temporary, limited privilege credentials to access your AWS resources so you do not have to use your AWS account credentials. The permissions for each user are controlled through AWS IAM roles that you create. You can define rules to choose the IAM role for each user, or if you are using groups in a Cognito user pool, you can assign IAM roles based on groups. Cognito identity pools also allows you to define a separate IAM role with limited permissions for guest users who are not authenticated. In addition, you can use the unique identifier that Cognito generates for your users to control access to specific resources. For example, you can create a policy for an S3 bucket that only allows each user access to their own folder within the bucket.

No, your app communicates directly with the supported public identity provider (Amazon, Facebook, Twitter, sign in with Apple, Google, SAML, or an Open ID Connect-compliant provider) to authenticate users. Cognito Identity does not receive or store user credentials. Cognito Identity uses the token from the identity provider to obtain a unique identifier for the user and then hashes it using a one-way hash so that the same user can be recognized again in the future without storing the actual user identifier.

No. Cognito Identity does not receive any confidential information (such as email address, friends list, etc.) from the identity providers.

Cognito identity pools supports the creation and token vending process for unauthenticated users as well as authenticated users. This removes the friction of an additional login screen in your app, but still enables you to use temporary, limited privilege credentials to access AWS resources.

Unauthenticated users are users who do not authenticate with any identity provider, but instead access your app as a guest. You can define a separate IAM role for these users to provide limited permissions to access your backend resources.

Yes, Cognito identity pools support separate identities on a single device, such as a family iPad. Each identity is treated separately and you have complete control over how your app logs users in and out and how local and remote app data is stored.

You can programmatically create a data set associated with Cognito identity pools and start saving data in the form of key/value pairs. The data is stored both locally on the device and in the Cognito sync store. Cognito can also sync this data across all of the end user’s devices.

The number of identities in the Cognito identity pools console shows you how many identities were created via the Cognito identity pools APIs. For Authenticated Identities (those logging in with a login provider such as Facebook or an OpenID Connect provider), each call to Cognito identity pools’ GetId API will only ever create a single identity for each user. However, for unauthenticated identities, each time the client in an app calls the GetId API will generate a new identity. Therefore, if your app calls GetId for unauthenticated identities multiple times for a single user it will appear that a single user has multiple identities. So, it is important that you cache the response from GetId when using unauthenticated identities and not call it multiple times per user.

The Mobile SDK provides the logic to cache the Cognito identity pools’ data automatically so you don't have to worry about this. If you're looking for a complete analytics solution for your app, including the ability to track unique users, please look at Amazon Mobile Analytics.

For Amazon Cognito user pool pricing, please see the Amazon Cognito pricing page.

To calculate estimated costs, use the AWS Pricing Calculator

You pay for Amazon Cognito user pools based on your monthly active users (MAUs). A user is counted as a MAU if, within a calendar month, your app generates an identity operation for that user, like administrative creation or update, sign-up, sign-in, sign-out, token refresh, password change, a user account attribute update, or an attribute query on a user (AdminGetUser API). You are not charged for subsequent sessions or for inactive users within that calendar month. Typically, your total number of users as well as your number of operations will be significantly larger than your total number of MAUs.

Use of SMS messaging to verify phone numbers, to send codes for forgotten or reset passwords, or for multi-factor authentication is charged separately. See the Worldwide SMS Pricing page for more information.

Yes, the Amazon Cognito user pools SKU and Essentials SKU are free for the first 10,000 MAUs. Customer accounts with active, Amazon Cognito user pools before Nov 21, 2024 are eligible for the free tier of a 50,000 MAUs.

As part of the AWS Free Tier, eligible AWS customers receive 10 GB of cloud sync store and 1,000,000 sync operations per month for the first 12 months.

Use of Amazon Cognito identity pools for authenticating users and generating unique identifiers is provided at no charge

There is no additional charge for using Cognito events to trigger Lambda functions, but normal rates for your use of AWS Lambda and other AWS services will apply while your Lambda functions are executing.

Please see the AWS Lambda pricing page for details.