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?

Skip a server check if the browser hides the delete buttonWhether this user may delete this specific projectAsk for the password again and allow deletion if it succeeds

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

Every sensitive action goes through an authorization check.

Current user→Authorization rule→Allow / deny
Apply roles and permissions

Beyond roles, check the relationship to the resource.

Current useru_23Post authoru_23ResultEdit allowed
Limit access by workspace or organization

Deny by default; allow as needed

DefaultDENYExplicitly allowviewer → read
Protect administrative and billing actions

Record administrative actions

16:42 · admin_u7disabled user_u23reason: repeated abuse

When NOT to use it

Rely on hidden buttons as access control

Hiding a button does not secure the endpoint.

PageNo delete button → Direct requestDELETE /users/42 → 204
Check a role but ignore which record is being accessed

An identity claimed by the frontend can be forged.

POST /api/admin/delete{ "userId": "u_23", "role": "admin" }
Grant broad administrator access for convenience

Signing in does not mean you can view all data.

Signed in→Access someone else's bill→Should be 403
Cache permissions without handling changes and revocation

The same rule is scattered across several places

users.tsCheck adminorders.tsForgot to checkreports.tsDifferent rule

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

Want GPT or Codex?VibeHubGPT support

GPT-6 Astra

Build in 3D. Put your computer to work.