Authentication versus authorization

Maya signs into a fictional reading club successfully. She can edit her own review, read published reviews, and see the date of the next meeting. She cannot change the club’s payment details. There is no contradiction: the service can be confident about her account and still deny an operation.

Ask a complete permission question

Authentication asks whether the claimant has demonstrated the expected account or authenticator control. Authorization asks whether a subject may perform an action on a resource under the current conditions. “Maya is allowed” is incomplete. “Maya may edit the review she owns while her membership is active” is much more useful.

The subject might be a person, an application, or an automated job. The resource might be a record, file, room booking, or administrative setting. Context can include the relationship to that resource, the current role, or a requirement for recent authentication. Naming each part reveals missing assumptions.

Roles are a starting point

A role groups permissions for a kind of work. The club’s event editor can update meeting descriptions; the treasurer can manage payment records. A member role alone does not explain which member’s review may be changed. Ownership or another relationship may be part of the rule.

Likewise, giving someone a role in one group should not silently grant that role in every group using the service. The organization or tenant context belongs in the decision. These distinctions are why one successful sign-in cannot replace all later permission checks.

The interface is not the authority

Hiding a button can make a screen easier to use, but the service must enforce its rule when it receives a protected request. The same operation may be reachable through different screens or through an application interface. Every supported path needs the appropriate checks.

This does not mean beginners need to invent their own access-control engine. It means designers should state the rules explicitly, use well-supported mechanisms, and verify both allowed and denied cases using fictional records in their own development environment.

PredictMaya’s event-editor role is removed, but an old browser tab still displays an Edit button. Should that tab preserve her editing permission?

No. The screen can be stale. The service should apply the current relevant policy when handling the operation. How quickly cached roles or issued tokens reflect a change is part of the design and must be accounted for.

Changes matter as much as sign-in

Permission can change during a session. A membership may end, a document may be transferred, or a sensitive operation may require stronger proof. A valid session and a current permission decision are different checks. Logout, role removal, and token expiry also have different meanings; none should be treated as a universal substitute for the others.

For the club, make the rule review concrete: a member edits their own review, an editor updates meeting details, and a treasurer changes payment settings after the required checks. Then ask about a different member’s review, a removed role, and a different club. Good explanations include why each request is allowed or denied.