Why the distinction matters operationally
A signed-in user is a known user, nothing more. The moment a system treats a valid session as evidence of entitlement, every record it can technically reach becomes reachable in practice. The failure is rarely dramatic — it looks like a viewer opening a page that lists payout details, or a technician loading a URL that was only ever linked from the owner's menu.
Keeping the two concepts separate forces a second question after every login: not just is this person real, but is this person allowed to do this specific thing to this specific record right now.
Where each check belongs
- Authentication: at the session boundary, producing a verified token.
- Authorization: at the data boundary, evaluated on every read and write.
- Route guards: a usability layer, not the enforcement layer.
- Interface state: a presentation layer, never an enforcement layer.
The test that exposes a conflated system
Take a low-privilege account, authenticate normally, and request a record it should not be allowed to see — by direct identifier, not by clicking. If the record comes back, the system authenticated you and never authorized you. That single test separates systems that check permission from systems that check presence.