5.Trace the step-by-step path of user credentials(such as an email/password or OTP login) from the public interface down to the database.
Login flow through a 3-tier architecture:
User → Internet. The user enters email/password (or OTP) in the browser or app. The request is sent over HTTPS (TLS), so credentials are encrypted in transit.
Internet Gateway → Public subnet. The IGW routes the request into the VPC, where it hits the load balancer / web tier. TLS is usually terminated here, and a WAF may filter malicious requests first.
Web tier → App tier. The web tier forwards the request to the application servers in the private subnet. The app tier's security group accepts traffic only from the web tier.
App tier validates the request. The app checks input format, rate limits attempts, and applies business logic (e.g., "is this account locked?").
App tier → Database tier. The app queries the database in the private subnet using its own DB credentials. The DB's security group accepts traffic only from the app tier.
Password login: The DB returns the stored salted hash (never the plain password). The app hashes the submitted password (bcrypt/Argon2) and compares.
OTP login: The app generates an OTP and stores it (usually hashed, with an expiry) in the DB or a cache like Redis. It's sent to the user via SMS/email service, and on submission the app compares the entered code against the stored one.
App tier issues a session. On success, it creates a session token or JWT and may log the event in the DB.
Response travels back. App → Web tier → Load balancer → Internet → User, over HTTPS. The browser stores the token (secure cookie) and sends it with later requests.
User → Internet. The user enters email/password (or OTP) in the browser or app. The request is sent over HTTPS (TLS), so credentials are encrypted in transit.
Internet Gateway → Public subnet. The IGW routes the request into the VPC, where it hits the load balancer / web tier. TLS is usually terminated here, and a WAF may filter malicious requests first.
Web tier → App tier. The web tier forwards the request to the application servers in the private subnet. The app tier's security group accepts traffic only from the web tier.
App tier validates the request. The app checks input format, rate limits attempts, and applies business logic (e.g., "is this account locked?").
App tier → Database tier. The app queries the database in the private subnet using its own DB credentials. The DB's security group accepts traffic only from the app tier.
Password login: The DB returns the stored salted hash (never the plain password). The app hashes the submitted password (bcrypt/Argon2) and compares.
OTP login: The app generates an OTP and stores it (usually hashed, with an expiry) in the DB or a cache like Redis. It's sent to the user via SMS/email service, and on submission the app compares the entered code against the stored one.
App tier issues a session. On success, it creates a session token or JWT and may log the event in the DB.
Response travels back. App → Web tier → Load balancer → Internet → User, over HTTPS. The browser stores the token (secure cookie) and sends it with later requests.