The model
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.
A concrete walk-through
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.
Costs and failure cases
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.
Check your understanding
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.