Cognito and Application Authentication

What it is

Amazon Cognito provides sign up, sign in and access control for the users of your web and mobile applications. It is the AWS answer when the people signing in are customers, not employees.

Cognito has two parts that people often confuse. A user pool is a user directory that authenticates users and issues tokens. An identity pool exchanges identities for temporary AWS credentials.

How it works

User pools

A user pool stores users or federates with external providers. After a successful sign in it returns three JSON Web Tokens (JWTs).

Features that matter for the exam:

• Hosted UI and managed login. A ready sign in page that supports OAuth 2.0 flows, including the authorization code grant.
• Federation. Sign in with social providers (such as Google or Apple), SAML identity providers and OIDC providers.
• MFA. SMS messages and TOTP (time based one time password) authenticator apps. MFA can be optional or required. Newer feature plans also add passwordless sign in with passkeys.
• Adaptive authentication. The advanced security (threat protection) features detect risky sign ins, such as compromised credentials or unusual locations, and can require MFA or block them.
• Lambda triggers. Run code at stages such as pre sign up, pre token generation and custom challenge, to add rules or custom claims.
• Groups. Assign users to groups, and the group appears in the token, which an authorizer or application can use.
• Password and account policy. Control password strength, verification and recovery.

Identity pools

An identity pool (federated identities) takes a proof of identity and returns temporary AWS credentials from STS. The proof can be a user pool token, a social token, a SAML or OIDC token, or nothing at all for guest access.

You define an IAM role for authenticated users and another for guests. Role selection can also map from token claims or groups to different roles.

Use an identity pool when the client app must call an AWS service directly, such as uploading to S3 from a mobile app. Scope the role tightly, and use the identity ID in the policy so each user reaches only their own prefix.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/${cognito-identity.amazonaws.com:sub}/*"
  }]
}

The variable expands to the caller's identity ID, so every user is confined to a personal folder.

Using Cognito with other services

Choosing between the parts

Token validation

A backend must verify tokens: the signature using the user pool's published keys, the issuer, the audience or client ID, the expiry and the token use (ID or access). API Gateway and ALB do this for you. A custom service must do it itself and must never trust claims from an unverified token.

Machine to machine access

For service to service calls, a user pool resource server can issue access tokens using the OAuth 2.0 client credentials grant, with custom scopes. This avoids creating fake users for backend clients.

Security hardening

Protect user pools with MFA, advanced security features, WAF rate limits, short token lifetimes and the revocation of refresh tokens when a user signs out or is compromised. Use a custom domain with a certificate for the hosted UI, and keep client secrets out of mobile apps, since public clients cannot keep secrets.