Amazon Cognito

Simple and Secure User Sign-Up, Sign-In, and Access Control

Service limitations

Soft limits - https://docs.amazonaws.cn/en_us/cognito/latest/developerguide/limits.html#limits-soft

Hard limits - https://docs.amazonaws.cn/en_us/cognito/latest/developerguide/limits.html#limits-hard

What to do when the soft limitation is hit?

It depends on the soft limit you're hitting, for the case of User Pools Resources soft limits, i.e. "A maximum number of users per user pool", the quick and easy solution is to reach AWS Support to extend them. Although you can work around all those limits by splitting resources anyway. For the example given before, it would be enough to create a new User Pool and define the way in your app to understand which User Pool to hit.

Regarding soft limits on Cognito API calls, it is as simple as make sure to include 500ms-1000ms delays between requests made in a loop.

How to tackle Amazon's hard limitations?

It would require a single article to go through each case, but the main idea is to define proper architecture so your usage of Cognito is good enough to not hit hard limits. In any case, you'll find it difficult to hit one of those limits, or it should be easy to avoid it if being hit.

From all those hard limits, you'd be facing typically the mailing one, so it is just better to configure your User Pool to use AWS SES instead of the default mail server from the beginning of your development. More info here.

Configuring the service

CDK script

const userPool = new CfnUserPool(this, userPoolName, {
  userPoolName,
  accountRecoverySetting: {
    recoveryMechanisms: [
      {
        name: 'verified_email',
        priority: 1,
      },
    ],
  },
  autoVerifiedAttributes: ['email'],
  usernameAttributes: ['email'],
  schema: [
    {
      name: 'email',
      required: true,
      attributeDataType: 'String',
      mutable: true,
    },
  ],
  policies: {
    passwordPolicy: {
      minimumLength: 6,
      requireLowercase: false,
      requireUppercase: false,
      requireNumbers: false,
      requireSymbols: false,
    },
  },
  emailConfiguration: {
    emailSendingAccount: 'DEVELOPER',
    sourceArn: `arn:aws:ses:${this.region}:${this.account}:identity/your-sender-email@email.com`,
  },
});
userPool.applyRemovalPolicy(RemovalPolicy.RETAIN);

const userPoolClient = new CfnUserPoolClient(this, userPoolClientName, {
  userPoolId: userPool.ref,
  clientName: 'web-client',
  generateSecret: false,
  explicitAuthFlows: [
    'ALLOW_ADMIN_USER_PASSWORD_AUTH',
    'ALLOW_USER_SRP_AUTH',
    'ALLOW_REFRESH_TOKEN_AUTH',
    'ALLOW_CUSTOM_AUTH',
  ],
});
userPoolClient.applyRemovalPolicy(RemovalPolicy.RETAIN);

Manual configuration

Step by step guide here.

Deploy

If using CDK, you'll need to configure your Cognito instance, and then run

cdk deploy ...

Otherwise, the service already exists for each AWS account.

Using the service

AWS Cognito is a pretty special service. Given its duty, it can be integrated with several services of the AWS family. Each one of these integrations strongly depends on the service where you are integrating them.

Anyway, you can use Cognito API to handle everything you need to manage User Pools, User Pool Clients, and Users. Find full API reference here.

In order to handle API, usually, you'd like to make use of AWS SDK. For example, find here the service that interfaces Cognito User Pool API for JavaScript.

Testing

Writing Unit Tests for any usage you do over this service is just to expect that you're calling the proper API endpoint or using the proper method from SDK.

Integration tests for this service would be as simple as check the response and make sure that you have the expected response for each one of the calls you are making against the service.

The way to do manual testing in Cognito is to navigate to the User Pool user list and check that the given user exists. Apart from that, you can log in with this user's credentials and check that tokens are provided in the response. If the option "remember devices" is enabled, you can check that new login in the devices list.

Logging

You will be able to see users' last activity date on the User Pool user list. If the "remember device" option is enabled, you'll see devices as a list as well.

For reading more detailed logs - use either CloudWatch or CloudTrail 

Debugging

If you suspect that something is not going well with some Cognito, you can always check the faulty operation using the Cognito HTTP API or debugging the same operation using AWS SDK Cognito Service Provider. Note that given its nature, it won't allow you to dive on token creation/refresh logics, so you can just need to expect that everything is going fine there (until now we didn't found any issue on this sense).

Rolling back

First, identify the nature of the issue, why you need to roll back. Usually, it is related to the configuration you're pushing. Make sure to check details on the error(s) thrown. If using CDK, it worths checking Cloudformation API to make sure that some required property is not being added in the configuration (it usually happens since CDK code sometimes is not completely in sync with Cloudformation API in terms of required attributes).

The last option is just to remove the instance of the service and create it again. If you have users there, do the backup to be able to restore them later on.

Backup

Simple and quick way, use cognito-backup-restore

Own code coming soon.

Restore

Simple and quick way, use cognito-backup-restore

Own code coming soon. 

Cost optimization techniques

This service must be up all the time for obvious reasons. It's worthy to note, that SAML authentication is approximately 10x more expensive than the native Cognito authentication.