Authorization

You might say

After people sign in, I still need different access levels for admins and regular users.

Decide what an authenticated user is allowed to see or changeAuthorization checks permissions for each resource and action after the user's identity is known. A person may view one project but not another, or edit content without managing billing. Enforce the rule on the backend for every request, not only by hiding controls in the interface.

Know first

Authentication Database

Current UserMember · Xiaolin

View itemsAllow

Edit own tasksAllow

Delete other people's tasksReject

Manage all accountsReject

Quick checkChoose the best answer

A signed-in member asks to delete a project from another team. What should be checked next?

Whether this user may delete this specific projectAsk for the password again and allow deletion if it succeedsSkip a server check if the browser hides the delete button

You can say this to an AI Agent

The delete-project endpoint checks only whether a user is signed in. Add a server-side ownership or team-role check. First have a same-team member without delete permission and a member of another team request the same existing test project; both must receive an explicit denial and leave it unchanged. Finally delete it as the owner and confirm the record is gone.

When to use it

Check record ownership
Apply roles and permissions
Limit access by workspace or organization
Protect administrative and billing actions

When NOT to use it

Rely on hidden buttons as access control
Check a role but ignore which record is being accessed
Grant broad administrator access for convenience
Cache permissions without handling changes and revocation

Anatomy

whocanwhatacts onwhich resource

Currently authenticated users, along with roles and memberships in trusted sources

The ability to read, edit, delete, approve, etc. requires judgment on an item-by-item basis

Target record, project or file; also check who owns it and which organization it belongs to

Variants

Role-based

viewer · editor · admin

Simple systems with clear roles.

Ownership

post.userId === me.id

Users may only operate on their own data.

Membership

project_members

Team and collaboration products.

Typical use cases

Project access

Personal dataJudge editing permissions based on resource ownership

Current useru_23Profile owneru_23ResultsAllow editing

Team roles

Project membersMembership determines viewing permissions

ProjectVibeHubUser roleviewerPermissionsViewable · Cannot be deleted

Admin settings

Administrator operationsBlock accounts and leave audit records

Target accountuser_42ReasonRepeated abuse

Confirm ban

Record admin_u7 · 16:42 · disable user_42

Billing permission

Paid functionSubscription status is confirmed by the server

Current PlanFree → Export HD filesRequires Pro

Hiding a control is not enough; the server must still check subscription access