鉴权：登录与权限Authentication & Authorization
一句话
鉴权先确认“你是谁”（认证），再判断“你能做什么”（授权），两步都必须在服务器上把关。
大白话
鉴权像公司门禁：刷工牌确认你是本公司员工，这是认证；这张工牌能不能打开财务室的门，是授权。
比喻的边界
网页上把“财务室”的按钮藏起来，不等于门锁上了；别人可以绕过页面直接调用接口，真正的锁必须装在服务器上。
拿去就能用
我在做，用户分成。帮我先列一张表：每种角色能看什么、能改什么。我确认后，再在服务器端加上权限检查，不要只在前端隐藏按钮。
还差：应用名称、用户角色，发给 AI 前记得换掉
普通用户登录后，在地址栏改掉文章 id，就能看到别人的私密文章。我怀疑接口只检查了是否登录，没检查文章属于谁。先帮我验证，再把所有类似的接口列给我，然后再改。
我想加“邀请成员协作”，被邀请的人只能编辑、不能删除项目。帮我设计角色和权限怎么存、每个接口怎么检查。改数据库和现有权限之前先告诉我影响，等我确认。
别这样说 → 这样说
别这样说
帮我做个登录，普通用户别让他看到管理按钮就行。
这样说
我的应用有普通用户和管理员两种角色，只有管理员能删除文章。帮我在删除文章的接口里检查身份和角色，不只是隐藏按钮。改完告诉我怎么用普通账号直接调接口，确认会被拒绝。
差别：把“看不到按钮”换成了“服务器拒绝请求”，并给出了验证办法。
误解前端把按钮藏起来、页面进不去，就等于做好了权限控制。
其实是前端检查只是为了体验，任何人都能绕过页面直接请求接口；每个读写数据的接口都要在服务器端检查“这个人能不能做这件事”；用 Supabase、Firebase 这类服务时，这道锁就是数据库的访问规则，不是前端代码。
展开专业理解
认证验证身份，常见方式有密码、验证码和第三方登录；授权判断这个身份能否执行某个操作，常按角色或资源归属来判断。认证成功后通常用 Session 或令牌记住身份。授权检查必须放在服务器端，每次请求都要查，客户端检查很容易被绕过。新手项目优先用成熟的登录服务或库，不要自己手写密码存储；密码只存加盐的慢哈希。
来源
- OWASP：授权速查表 核对于 2026-09-26
- OWASP：认证速查表 核对于 2026-09-26