Separate identity, authentication, and authorization

Authentication verifies a claim about who is calling. Authorization decides what that authenticated identity may do. An account record and a session are related but different things.

Keep four questions separate:

1. Identity: which account is this?
2. Authentication: what proof did the caller present?
3. Session: how does the server remember that proof across requests?
4. Authorization: may this account perform this action on this resource?

Our project secures the Books API. A user signs in, receives a session, and can manage books they own. The server must derive the owner from the trusted session, not from a user ID submitted in the request body.

This request value is untrusted:

{ "title": "The Hobbit", "ownerId": "user-42" }

The handler should ignore ownerId. It gets the user ID from the validated session and writes that value itself.

A successful login answers only the authentication question. It does not prove the user is an administrator or owns book 17. Make the authorization decision again at every protected operation.

This separation also improves failures. A missing session is an authentication failure. A valid session requesting someone else’s book is an authorization failure. A database outage is neither.

Draw signup, login, authenticated request, authorization decision, and logout as separate steps. Label the trusted input at every boundary.