How does serverless identity with Amazon Cognito work?

Separate authentication from authorization

Authentication establishes who the caller is. Authorization decides what that identity can do in this application and resource context. A valid token proves an authentication result but does not by itself enforce tenant ownership or every domain rule.

Validate issuer, audience or client, signature, expiration, token use, and required scopes or claims at the API boundary. Then apply resource-level authorization before accessing data or causing side effects.

Use user pools and identity pools for different needs

A user pool manages sign-up, sign-in, federation, account recovery, tokens, and related directory features. An identity pool is used when clients need temporary AWS credentials mapped to authenticated or unauthenticated identities.

Many applications need a user pool but not an identity pool because clients call an API rather than AWS services directly. Add direct AWS credentials only for a concrete access pattern and tightly scoped role policy.

Design the complete account lifecycle

Cover registration, verification, sign-in, multifactor authentication, federation, refresh, sign-out, recovery, email or phone changes, account disablement, deletion, and support intervention. Abuse controls and rate limits belong in the same design.

Avoid putting rapidly changing authorization state only in long-lived token claims. Define how role or tenant changes take effect and how sessions are revoked or constrained after a security event.

Enforce tenant and resource boundaries in data access

Derive trusted identity from validated credentials, never from an unverified request field. Bind database keys, object prefixes, queue operations, and business rules to that trusted context.

Log security-relevant actions without storing tokens or sensitive claims. Test cross-user and cross-tenant denial cases, confused-deputy paths, deleted accounts, stale sessions, and administrator operations.