Interview prompt
Explain authentication, sessions, and authorization to an engineer who understands the surrounding system but has not used this technique. Walk from its contract to a concrete operation, then discuss where it fails or becomes expensive.
A strong answer
Authentication answers who or what is making a request; authorization decides which actions that identity may perform on a resource. A session binds later requests to an authenticated context. Keeping these decisions separate makes access rules easier to audit and change.
After login, a server can create a random session identifier and store session state server-side, sending the identifier in a protected cookie. On each request, it resolves the session and checks whether the user may access the requested object. Object ownership must be checked at the resource boundary, not inferred from a hidden UI link.
A complete answer also calls out the assumptions that control correctness. Signed tokens can reduce lookup needs but complicate revocation, expiration, and claim freshness. Cookies need secure transport and appropriate SameSite and HttpOnly settings. Authentication success alone must never imply permission to read every record associated with a guessed identifier.
Close by describing one representative test or measurement. A user changes a URL from /orders/123 to /orders/124 and sees another account’s order. Identify the missing server-side check and one test that would catch the flaw.
Follow-up questions
Answer the follow-ups in the frontmatter. Use the linked article for the concept and the trace to make the explanation concrete.