Authentication identifies the actor; authorization still has to check the object

Authentication establishes who is making a request. Authorization decides whether that actor may perform this action on this object in the current context. The decisions are related but not interchangeable: public material can be intentionally accessible without login, while a logged-in user can still be denied a private record.

Illustrative example: two colleagues can both sign in to a document service. One owns a private draft. The second colleague's successful login does not establish permission to read that draft, even if they know its identifier.

A useful review question is: where does the service verify the actor-to-resource relationship for every read and write? Hiding a button or using unpredictable identifiers can improve the interface or reduce guessing; neither substitutes for that decision. Test both permitted and forbidden actors against the same object, and the same actor against differently owned objects.

Scope limit: the applicable policy can include roles, relationships, attributes, and intentional public access. The distinction does not prescribe one universal policy model, and checking identity alone cannot establish that a policy was enforced.