This demo uses a two-step email verification flow with OTP for account creation, password recovery, and user deletion.
This demo is a reference implementation designed to illustrate practical security choices in an AWS serverless architecture. It is intentionally simplified, but it maps directly to the AWS Well-Architected Security Pillar across identity, data protection, detection, infrastructure protection, incident response, and application security.
Each sensitive action follows a zero-trust mindset: requests are treated as untrusted by default, and the design aims to support least-privilege access with narrow request boundaries to reduce exposure of sensitive data.
OTP is used to verify email ownership and as an additional verification step alongside the password for sensitive actions such as login and deletion. Passwords are required for login, account creation, and deletion.
Request IDs are logged to support traceability without exposing secrets, and the logging pattern can be extended to CloudWatch alerting for anomaly detection.
The architecture is fully serverless and uses strict API boundaries, along with restrictive CORS, to reduce unnecessary attack surface. The backend is stateless, with no application server persisting runtime state between invocations.
Secrets are hashed with one-way cryptographic functions before being stored in the database, reducing exposure if storage is accessed by authorized operators. Transport security is enforced with TLS 1.3+ to protect data in transit. Query parameters are URL-encoded for correctness, while confidentiality in transit is provided by TLS.
OTP expiry, clear failure states, and controlled delete flows support safe recovery and response.
User input is validated on the client side before being sent to the API. Strict CORS helps limit which browser origins can call the API, but backend validation remains the primary security control.
This is a demo, not a production service. It intentionally highlights both strengths and trade-offs, including client-side compromise, email-based OTP limitations, static secret questions, cloud-provider dependency, and jurisdictional data considerations.
This page was created through a human-led process, with AI used for polishing, wording refinement, and presentation assistance. The core product thinking, architecture decisions, security analysis, and overall design direction are human-authored.
It keeps the workflow simple to understand, shows security as a deliberate design choice, and demonstrates how AWS serverless services can support a secure, explainable identity flow.
Even with TLS 1.3+, secrets can still be exposed if the client device is compromised by malware, remote access tools, or keyloggers.
OTP via email is only effective if the attacker does not already control the victim’s email account or device session.
Static secret questions can be vulnerable to social engineering. Requiring three correct answers reduces risk, but does not eliminate it.
Using Lambda, DynamoDB, and API Gateway improves operational simplicity and elasticity, but introduces some cloud-provider lock-in compared with container-based portability.
The demo keeps data collection minimal and uses a consent-driven flow, but production deployments should still consider regional jurisdiction, retention, and compliance requirements.