Design an Authenticated Online Shopping Service

## Prompt Design an online shopping service centered on user authentication and authorization. Cover signup, login, session or token handling, product browsing, a user-owned cart, and placing an order. Explain how APIs prevent one user from reading or changing another user's resources. ### Constraints & Assumptions - Passwords are never stored in plaintext. - Cart and order ownership is derived from the authenticated principal, not a trusted client-supplied user ID. - Order creation must be safe to retry after a timeout. - Payment processing details are out of scope; the service records a pending order. ### Clarifying Questions to Ask - Should the client use server sessions or short-lived access tokens with refresh rotation? - Are guest carts required, and how should they merge after login? - Which actions require elevated administrative roles? ```hint Authenticate once, authorize every resource A valid session proves who the caller is; each service method must still verify that the requested cart or order belongs to that principal. ``` ### What a Strong Answer Covers - Identity tables, password hashing, verification, recovery, and session lifecycle. - Authorization checks on cart, order, product-management, and admin APIs. - CSRF, token theft, rate limiting, enumeration, and secure-cookie considerations. - Idempotent order creation and transactional conversion of a cart snapshot. - Logging, revocation, tests, and user-safe error behavior. ### Follow-up Questions 1. How would you revoke all sessions after a password reset? 2. How would you support social login without tying domain data to one provider identifier? 3. What changes when administrators may issue refunds but must not see password credentials?