AWS Cognito

At a glance

AWS Cognito is worth considering when you want managed sign-up and sign-in alongside an AWS application and can budget for authentication integration. It is Amazon’s hosted identity service, with two distinct jobs: user pools issue tokens for your app, while identity pools exchange trusted identities for temporary AWS credentials. Most applications that only need users to sign in can start with a user pool. Adding both components by default creates work that the application may not need.

Good fit

Teams already working with AWS that want a managed user directory, social or enterprise federation, and a choice of managed login pages or a custom interface. A user pool can standardize external sign-ins into one token format for your backend. Identity pools become useful when a client must access AWS resources directly under an IAM role. Machine-to-machine authorization is another path: an application obtains an access token as itself, rather than impersonating a human user.

Consider something else when

You expect a login page to finish application authorization for you, or want a setup that hides OAuth, token validation and cloud configuration. Your API still needs to verify tokens and enforce access to its own resources. A browser or mobile public client cannot protect an embedded client secret; the documented public-client flow uses authorization code with PKCE, which binds the token exchange to the original sign-in request. Some user-pool sign-in settings cannot be changed after creation, so an early configuration choice can add migration work later.

Start here

In a separate evaluation environment, open the Cognito console and choose Create user pool, then select the application type matching your app and configure its sign-in identifiers and return URL. The console creates a user pool and app client and supplies platform examples. For a browser app, check that the public client has no embedded secret and uses authorization code with PKCE. The first useful result is a managed-login round trip that returns to your application, followed by backend verification of the token’s signature, issuer, expiry, client binding, token type and required scopes. This is a documented evaluation path; no AWS resources or test users were created for this review.

Cost and requirements

Pricing checked 31 October 2026 gives Lite and Essentials 10,000 monthly active users for direct or social sign-in per account or organization, with eligible legacy Lite use retaining a 50,000-user allowance. Plus has no direct/social free tier. SAML/OIDC federation has a separate 50-user allowance, and machine-to-machine token requests have no free tier. Identity-pool authentication and identifier generation are listed at no charge; accessed AWS resources and SMS delivery have their own charges. Essentials is the default for new pools. An AWS account, suitable permissions and application integration are required; the old blanket “free up to 50,000 MAU” claim does not describe every new setup.

Limits to know

A valid-looking JWT is not sufficient authorization. Offline signature and expiry checks also do not establish that a token has not been revoked; session lifetime and revocation behavior need deliberate handling. User profiles and authentication are managed in the service rather than stored only in your app. Existing passwords cannot be retrieved from user profiles, so directory migration needs a plan beyond copying account attributes. This source-based review did not configure federation, test account recovery or migration, create a live login, validate an API integration or assess operational reliability.

Related work

• Amazon: organization behind the AWS identity service (context)