Security best practices for Amazon Cognito identity pools

Amazon Cognito identity pools provide temporary AWS credentials for your application. AWS accounts often contain both the resources that your application users need, and private back-end resources. The IAM roles and policies that make up AWS credentials can grant access to any of these resources.

The primary best practice of identity pool configuration is to ensure that your application can get the job done without excess or unintended privilege. To guard against security misconfiguration, review these recommendations before the launch of each application that you want to release to production.

IAM configuration best practices

When a guest or authenticated user initiates a session in your application that requires identity pool credentials, your application retrieves temporary AWS credentials for an IAM role. The credentials might be for a default role, a role chosen by rules in your identity pool configuration, or for a custom role chosen by your app. With the permissions assigned to each role, your user gains access to your AWS resources.

For more information about general IAM best practices, see IAM best practices in the AWS Identity and Access Management User Guide.

Use trust policy conditions in IAM roles

IAM requires that roles for identity pools have at least one trust policy condition. This condition can, for example, set the role’s scope to authenticated users only. AWS STS also requires that cross-account basic authentication requests have two specific conditions: cognito-identity.amazonaws.com:aud and cognito-identity.amazonaws.com:amr. As a best practice, apply both of these conditions in all IAM roles that trust the identity pools service principal cognito-identity.amazonaws.com.

The following example role trust policy grants access to a role under the following conditions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "us-east-1:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

Apply least privilege permissions

When you set permissions with IAM policies for authenticated access or guest access, grant only the specific permissions required to perform specific tasks, or least privilege permissions. The following example IAM policy, when applied to a role, grants read-only access to a single image file in an Amazon S3 bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": ["arn:aws:s3:::mybucket/assets/my_picture.jpg"]
    }
  ]
}

Identity pool configuration best practices

Identity pools have flexible options for the generation of AWS credentials. Don’t take design shortcuts when your application can work with the most secure methods.

Understand the effects of guest access

Unauthenticated guest access permits users to retrieve data from your AWS account before they sign in. Anyone who knows your identity pool ID can request unauthenticated credentials. Your identity pool ID isn’t confidential information. When you activate guest access, the AWS permissions that you grant to unauthenticated sessions are available to everyone.

As a best practice, leave guest access deactivated and fetch required resources only after users authenticate. If your application requires access to resources before sign-in, take the following precautions.

Use enhanced authentication by default

With basic (classic) authentication, Amazon Cognito delegates selection of the IAM role to your app. In contrast, the enhanced flow uses the centralized logic in your identity pool to determine the IAM role. It also provides additional security for unauthenticated identities with a scope-down policy that sets an upper limit on IAM permissions. The enhanced flow is the most secure choice with the lowest level of developer effort. To learn more about these options, see Identity pools authentication flow .

The basic flow can expose the client-side logic that goes into role selection and assembly of the AWS STS API request for credentials. The enhanced flow hides both the logic and the assume-role request behind identity pool automation.

When you configure basic authentication, apply IAM best practices to your IAM roles and their permissions.

Use developer providers securely

Developer authenticated identities are a feature of identity pools for server-side applications. The only evidence of authentication that identity pools require for developer authentication are the AWS credentials of an identity pool developer. Identity pools don’t enforce any restrictions on the validity of the developer-provider identifiers that you present in this authentication flow.

As a best practice, only implement developer providers under the following conditions: