Authentication vs Authorization
Distinguish identity from permission to act. · Technical Fluency · Lesson 23 · 3 min
Authentication vs Authorization · 3 min
Situation
Signed in does not mean allowed.
A contractor signs into a Slack-style workspace. They should read the project channel they were invited to, but not the finance channel or billing settings.
A successful login establishes identity for the session. It does not give every authenticated person the same access.
Mental model
Two questions at different boundaries.
Authentication asks who you are. Authorization asks whether this identity can perform this action on this resource in this context.
Roles such as member and admin are one way to express permissions. Access can also depend on workspace membership, ownership, resource visibility, or other attributes.
Example
Check the resource as well as the role.
A person may be an admin in Workspace A and an ordinary member in Workspace B. An “is admin” flag without workspace context could grant the wrong access.
For a channel export, check the relevant workspace, channel, operation, and policy. Enforce authorization on the server for each protected request; hiding a button is only part of the interface.
Failure case
Revocation arrives too late.
A contractor is removed, but an old session or cached response still exposes data. The product needs defined behavior for revoked access, active sessions, exports, and shared links.
Ask how quickly revocation takes effect and which previously downloaded information cannot be recalled. Permissions are a lifecycle, not only an invitation setting.
Before scrolling
Explain authorization in one sentence.
Use a concrete resource and action. Then explain why a logged-in user might still receive a permission error.
Consider whether the interface should reveal that a protected resource exists. The right error behavior may depend on confidentiality as well as helpfulness.
A strong answer
Permission is specific to the action.
Authorization determines whether an identity is allowed to access or change a particular resource. A signed-in member may be allowed to read a channel but not invite guests or change billing.
For a PM, the useful next step is a permission matrix covering roles, resources, actions, and exceptions, reviewed with engineering and security.
Remember this
Login is the beginning of access control.
Specify who can do what, where, and what happens when that permission changes. Make denied states understandable without exposing protected information.