Secure Application Authentication with Amazon Cognito
Users authenticate with Cognito before API Gateway invokes application logic that accesses private DynamoDB data.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasSecure AWS authentication architecture diagram with Amazon Cognito, API Gateway authorizer, Lambda, and DynamoDB. The image links to a fully editable BuildPlane starter.
Overview
Users authenticate with Amazon Cognito and send an access token to Amazon API Gateway. The gateway validates the token before invoking AWS Lambda, and Lambda accesses DynamoDB from the application layer. Identity checks remain at the API boundary, and clients never connect directly to the data store.
Components
- Amazon Cognito: Registers users, handles sign-in, and issues short-lived tokens containing identity claims.
- Protected API: Uses a Cognito authorizer to validate tokens before a request enters the application.
- Application Function: Applies business authorization and performs operations for the authenticated user.
- Private Application Data: Stores records behind the application boundary rather than exposing direct client access.
Authentication Flow
- The user signs in with Cognito and receives an identity token.
- The client presents that token to the protected API route.
- API Gateway validates the token before invoking the Lambda function.
- Lambda applies application-level authorization and reads the user’s DynamoDB records.
Customize First
- Define user groups and claims around real application roles.
- Add MFA and account-recovery rules that match the application risk level.
- Use least-privilege IAM permissions for the function’s DynamoDB access.
Related AWS guides
Understand the decisions behind this diagram
Use these practical explanations to compare services, failure boundaries, and operating tradeoffs before adapting the architecture.
Design rationale
Decisions that shape this architecture
Authenticate at the managed identity boundary
Cognito handles sign-in, recovery, token issuance, and optional federation. The application does not store or verify raw passwords itself.
Reject invalid tokens before invoking business logic
An API Gateway authorizer validates the token at ingress. Lambda still owns authorization decisions that depend on the requested resource or business role.
Keep data access behind the application
Clients do not connect directly to DynamoDB. The Lambda execution role receives only the table actions and key scope required by the API.
Before production
Operational checks
Define token lifetimes and refresh behavior for the actual client risk model.
Require MFA where account impact justifies the added friction.
Validate issuer, audience, expiry, and required claims on every protected route.
Log authorization failures without recording tokens or sensitive claims.
Scope and tradeoffs
What this diagram does not solve
Authentication does not decide every authorization rule
A valid token proves identity and carries claims. The application must still verify tenant, ownership, role, and operation-specific permissions.
Account lifecycle needs product decisions
Registration, verification, recovery, deletion, federation, and support workflows need deliberate policies beyond the request path shown here.
Common questions
Frequently asked questions
What does Cognito provide in this architecture?
Cognito manages user identity and issues tokens. API Gateway validates those tokens before invoking the application function.
Should Lambda trust every claim in a valid token?
Lambda can trust properly validated claims from the configured issuer, but it must still apply application authorization for the requested data and action.
Can Cognito federate external identity providers?
Yes. Cognito user pools can support social and enterprise federation, but provider setup and claim mapping should be designed and tested explicitly.
Keep exploring
Related AWS architectures
Serverless REST API Architecture on AWS
This is the serverless API baseline that most production APIs grow from rather than away from: a managed HTTPS entry point, stateless function compute, on-demand data storage, and observable execution. It is deliberately compact so the first real decisions stay legible. Adding authentication, caching, asynchronous work, and a second Region each attaches to this shape without replacing it, which is why it is worth understanding before the additions arrive.
Explore the architecture
Secure File Upload and Malware-Scanning Pipeline on AWS
This architecture keeps large upload bytes out of the API, lands every object in an encrypted trust boundary, scans before promotion, quarantines suspicious files, and exposes processing status to the application. It is a security-focused workflow rather than a generic upload shortcut.
Explore the architecture
Serverless Multi-Tenant SaaS Architecture on AWS
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.