接手过不少系统第一件事先看登录和权限是怎么设计的。有些系统登录用的挺顺但换个角色就漏出各种权限洞有些系统权限控制得很严但每次登录过个十几分钟就掉线。这些问题的根源大多出在没搞清楚身份认证Authentication和权限授权Authorization这两件事上一个管“你是谁”一个管“你能干什么”。这两个概念看着简单实际落地时坑非常多而且一旦基础设计选型错了后面改起来基本等于重写。这篇就从核心原理、方案选型、落地实现到问题排查把权限认证这摊子事一次捋清楚希望对正在做登录鉴权、权限管理的朋友有点参考价值。不管你是刚接手老项目还是准备从零设计一套权限体系这篇的内容都适用。1. 先掰扯清楚认证和授权到底差在哪1.1 一个现实中的类比5分钟看懂两者关系很多人把认证和授权混着说面试时也经常听到“做一下权限认证”这种含糊的说法。但实际在系统里这是两个不同的环节必须严格区分。可以拿小区门禁来类比。进入小区大门时要刷门禁卡这张卡验证你是不是这个小区的住户这就是认证Authentication——证明“你是谁”。进了小区之后你能进A栋楼但进不了B栋楼因为B栋有独立门禁这就是授权Authorization——证明“你能干什么”。放到系统里认证解决的是“你是合法用户吗”常见手段有用户名密码、短信验证码、扫码登录、指纹、第三方登录等。认证通过后系统通常要给你发一个凭证相当于一张“通行卡”后续请求带着它系统才知道是“谁”在操作。授权解决的是“这个合法用户能操作哪些资源”常见手段有RBAC角色权限、ACL访问控制列表、ABAC属性权限等。授权发生在认证之后系统已经知道你是谁然后查一下规则判断你能不能访问这个接口、能不能看到这组数据、能不能点那个按钮。有个非常关键的次序问题认证在前授权在后。系统不可能对一个未认证的用户做授权校验因为根本不知道他是谁。但反过来也重要认证通过绝不代表能访问所有资源这是很多新手写代码时最容易犯的错——登录成功就直接放行全部接口认为用户已认证就等于有全部权限。1.2 术语拆解Authentication、Authorization 和 Authentication顺带把三个相关术语都理一下因为它们长得太像了不少人记混。Authentication身份认证验证用户身份确认“你声称你是的这个人确实是你”。核心是凭证校验。Authorization权限授权授予或验证用户对特定资源的操作权限关注的是“你有什么权利”。Identity / Account身份标识用户的唯一标识比如用户ID、用户名、手机号。认证的结果通常就是得到一个可信的标识。实际开发中它们三者的关系是这样的用户输入身份标识 凭证系统完成Authentication后拿着可信的身份标识去查询该标识对应的权限集合再对用户的每一次访问做Authorization校验。很多人只做了Authentication忽略了Authorization后果就是“登录后所有接口都能调”这在内部管理系统里尤其危险。1.3 常见误区登录成功不等于权限正确举一个我见过的真实案例。某后台系统A用户是普通运营B用户是管理员。代码里只做了登录拦截没有做管理员接口的权限控制。A用户手贱把浏览器的用户ID从100084改成100001管理员的ID再刷新页面竟然看到了管理员的全部菜单和数据。这就是典型的只做了Authentication没做Authorization身份可以被伪造或篡改权限完全失效。还有一个误区前端隐藏菜单就当做了权限控制。很多项目用Vue或React登录后根据角色动态渲染菜单没权限的菜单隐藏掉。但前端隐藏只是视觉层面的接口照样可以被直接调用。权限控制的底线必须放在后端前端只是在体验上做辅助。2. 身份认证方案选型Session、JWT、OAuth2到底选哪个2.1 Session认证适合传统单体、强服务端控制的场景Session认证是历史最悠久的方案。用户提交用户名密码服务端校验成功后生成一个Session记录存在服务端内存或Redis里同时把Session ID通过Cookie返回给浏览器。浏览器后续请求自动带上Cookie服务端根据Session ID查到对应的会话。Session方案最大的优点是可以随时在服务端销毁会话比如强制用户下线、封禁账号只需删除对应的Session记录就行。权限和会话状态都在服务端控制力最强。缺点是服务端要存状态集群部署时需要解决Session共享问题Cookie在跨域场景下比较麻烦移动端App要手动管理Cookie非常别扭。适用场景传统管理后台、单体应用、需要严格会话管控的系统。如果项目是经典的前后端一体开发Session依然是个可靠选择。2.2 JWT认证无状态是优点也是软肋JWTJSON Web Token是目前最流行的认证方案之一。认证成功后服务端签发一个包含用户标识、过期时间等信息的Token客户端存起来每次请求放到Header里。服务端不再保存会话状态校验时验签即可。JWT的最大优势是无状态天然支持分布式、水平扩展也不用存Session。但它有几个必须注意的软肋Token一旦签发在过期之前无法主动使其失效。用户被禁用了Token还是能继续用除非额外做黑名单机制这又回到了有状态的路上。Token体积比Session ID大不少请求头塞一个长字符串对网络带宽有点浪费。密钥管理要求高一旦密钥被泄露攻击者可以自己伪造Token整个认证体系形同虚设。适用场景前后端分离项目、小程序、App接口、微服务间认证。现在的用户中心、开放平台JWT基本是标配。2.3 OAuth2/SSO多系统、第三方登录的正确姿势当你的系统多了用户不希望在一个体系里注册N套账号于是有了SSO单点登录。SSO的核心是独立的认证中心多个业务系统共享一套登录态。OAuth2则是更通用的授权框架常用于第三方登录授权比如让用户用某个平台的账号登录你的系统。这里要提醒一下OAuth2不是认证协议它是授权协议。它的核心场景是“允许第三方应用代表用户访问资源”比如允许某个工具读取你的网盘文件列表。如果用OAuth2做单点登录还需要额外引入OpenID Connect这类身份认证层才能拿到用户身份信息。实际项目中有一些团队直接用OAuth2的Authorization Code流程实现单点登录逻辑上能跑通但理解上要清醒流程结束时你拿到的是Access Token还需要调用用户信息接口换取身份然后建立本地会话。2.4 选型建议总结我整理了一个自己的选型判断表格供参考场景类型推荐方案理由传统单体管理系统Session Cookie服务端可控强制下线方便技术成熟前后端分离后台JWT或Session存Redis避免跨域Cookie问题分布式友好纯API服务、小程序JWT无状态客户端集成简单多系统/多应用SSO认证中心统一登录态账号体系集中管理对接第三方登录OAuth2 OIDC标准协议避免自造轮子选择的标准不是“哪个新用哪个”而是看你的系统中“需要服务端主动失效会话吗”“跨域部署复杂吗”“客户端形态是什么”。这些问题想清楚了方案自然清晰。3. 权限授权模型RBAC、ABAC、ACL 应该怎么选3.1 RBAC角色权限模型管理后台的默认答案RBACRole-Based Access Control是目前运用最广泛的权限模型核心思路很简单用户不直接关联权限而是通过角色间接关联。比如“运营”角色拥有“订单查看、商品编辑”权限“管理员”角色拥有全部权限。RBAC的优点是模型直观、管理方便、适合权限相对稳定的系统。新增用户时只需给他分配角色不用一条一条配置权限。实际落地时通常有两种模式基础RBAC用户-角色-权限三级角色直接绑定权限。扩展RBAC增加用户组概念用户属于组组对应角色便于批量管理。设计数据库模型时通常涉及五张核心表用户表、角色表、权限表、用户角色关联表、角色权限关联表。有些系统还要加用户组表、用户组成员表。下面是一个典型的关系设计示例。-- 用户表 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY, username VARCHAR(64) UNIQUE, password VARCHAR(128), nickname VARCHAR(64) ); -- 角色表 CREATE TABLE sys_role ( id BIGINT PRIMARY KEY, role_code VARCHAR(64) UNIQUE, role_name VARCHAR(64) ); -- 权限表 CREATE TABLE sys_permission ( id BIGINT PRIMARY KEY, perm_code VARCHAR(64) UNIQUE, perm_name VARCHAR(64), type VARCHAR(16) -- menu/button/api/data ); -- 用户角色关联表 CREATE TABLE sys_user_role ( user_id BIGINT, role_id BIGINT, PRIMARY KEY (user_id, role_id) ); -- 角色权限关联表 CREATE TABLE sys_role_permission ( role_id BIGINT, permission_id BIGINT, PRIMARY KEY (role_id, permission_id) );这个结构看着简单但要注意权限表的type字段。开发时很容易只设计菜单权限把页面可见性当作全部权限最后发现接口权限、按钮权限、数据权限没地方放又得重建表。所以我建议一开始就把权限类型考虑进去区分菜单权限、操作权限、接口权限、数据权限为后面扩展留余地。3.2 ABAC属性权限模型复杂业务权限的解法RBAC的缺点是当权限规则非常复杂时角色数量会爆炸。比如“销售能看自己区域内的订单区域经理能看整个大区的订单财务专员能看所有已付款订单”这种规则如果全用角色表达角色列表会又长又难维护。ABACAttribute-Based Access Control是基于属性的权限模型。它把权限判断建立在主体属性、资源属性、环境条件之上。比如主体属性用户所属部门、职位级别、职级、所在地区。资源属性订单归属销售员、订单所属区域、订单状态。环境属性访问时间、登录IP、访问设备。授权策略不再是“角色A有权限B”而是“如果满足条件组合则允许访问”。比如一条策略可以写成允许 访问订单列表 当 订单.区域 用户.所属区域 且 订单.状态 in (已付款, 已发货)ABAC非常灵活但落地成本也高需要定义属性、规则引擎、策略管理界面。中小型项目直接上ABAC容易过度设计反而是给自己找麻烦。我的经验是大多数管理后台用RBAC就够了如果某些模块确实需要数据级权限可以局部引入数据权限规则而不是全系统上ABAC。3.3 ACL访问控制列表最原始也最直接ACLAccess Control List是最古老的授权模型直接在资源上列出“谁可以做什么”。比如文件系统里每个文件记录了哪个用户能读、哪个用户能写。ACL足够简单、精确但用户一多、资源一多维护ACL的成本会急剧上升。ACL在业务系统里较少作为主权限模型使用但在某些特定场景很合适比如文档系统的分享设置、网盘的文件权限、配置中心的某项配置针对特定用户开放。它常作为RBAC的补充解决“单个特例”的授权需求。3.4 权限模型选型的取舍用一句话总结我自己的选型经验能用RBAC解决的不要上ABACACL作为补充机制不要作为主模型。权限模型的复杂度应该跟业务复杂度匹配模型越复杂开发维护成本越高而且权限系统本身的bug越难排查。很多团队一上来就设计了个巨大的权限引擎结果半年后没人敢动那套代码——这就是过度设计。4. 从登录到鉴权核心流程设计与落地实操4.1 登录认证的标准流程拆解不管用Session还是JWT一个健壮的登录流程都包含以下几个环节凭证输入与传输用户名 密码务必通过HTTPS传输防止明文被抓包。参数校验先做基础校验用户名密码非空再做安全策略校验比如验证码、登录失败次数限制。密码校验从数据库读取用户信息用存储的哈希值验证明文密码。绝对不能用明文密码或可逆加密存储。状态检查确认用户状态是否正常未激活、被禁用、已删除的账号不能登录。签发凭证生成Session或JWT记录登录信息。记录日志记录登录成功/失败时间、IP、设备信息便于安全审计。这里重点强调密码存储。用MD5直接存密码早就过时了正确做法是用bcrypt、scrypt或argon2这类专门设计的密码哈希算法。bcrypt的优势在于它内部自带盐且可以调整计算成本参数同一密码每次生成的哈希都不一样还能抵御暴力破解。推荐直接使用成熟的库比如Java的jBCrypt、Node的bcryptjs、Python的bcrypt。一个典型的用户密码存储流程是注册时生成哈希后写入数据库登录时将用户输入明文与数据库中的哈希做校验。尽量少自己写加密算法这是花式踩坑的重灾区。我见过有同事把用户密码按字符做了一个简单的替换表之后就存进数据库表面上看是“加密了”实际上一个正则工具就能还原出来。存储密码的哈希不是给黑客准备的是给你自己的系统兜底的。一旦数据库泄露密码哈希不能直接被还原成明文用户在其他平台的密码也不会受到牵连。4.2 JWT的签发、刷新与安全注意点用JWT做主认证时Token策略设计得当能解决很多后续麻烦。一个标准的JWT包含Header、Payload、Signature三部分Payload里一般放用户ID、登录时间、过期时间等非敏感信息签名部分由服务端密钥生成。签发Token时我建议把过期时间设短一点比如2小时然后用一个Refresh Token刷新令牌来续期。Refresh Token过期时间可以长些比如7天或14天。客户端在Access Token即将过期时拿Refresh Token换取新的Access Token。这样即使Access Token泄露攻击者的利用窗口也被压缩了。一个常见的坑是Refresh Token没有做失效控制既不存服务端也不做版本号用户修改密码后旧Refresh Token还能继续换新Token。解决方法是给Refresh Token加版本号或者存Redis每次换新时校验版本密码修改时版本号加1旧令牌全部作废。密钥管理方面JWT的签名密钥要放进环境变量或配置中心不要写死在代码库。一旦怀疑密钥泄露需要立即更换密钥并让所有用户重新登录。如果分布式部署各节点必须使用同一个密钥或同一个公钥/私钥对否则会出现“这个节点签发的Token另一个节点验证失败”的问题。下面是一段典型的JWT校验中间件逻辑Java为例逻辑表达与语言无关public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { String token extractTokenFromHeader(request); if (token null || token.isEmpty()) { throw new UnauthorizedException(缺少Token); } try { Claims claims Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(token) .getBody(); request.setAttribute(userId, claims.get(userId)); // 还可从库里加载用户最新状态做额外的失效校验 } catch (JwtException e) { throw new UnauthorizedException(Token无效或已过期); } chain.doFilter(request, response); }注意上面只完成了Authentication即“这个请求是谁发出的”。接下来的Authorization校验还需要一层权限过滤器判断该用户是否有权限访问此接口。经常有团队把两件事放在一个过滤器里或者只做前者不做后者结果就是认证通过后访问任意接口都畅通无阻。4.3 后端权限拦截如何设计接口级权限校验接口级权限校验通常的做法是给每个接口定义一个权限标识比如order:query、order:update、user:delete然后通过注解或配置绑定到接口上。用户登录后系统加载该用户拥有的全部权限标识在请求到达接口前校验当前用户的权限集合中是否包含该接口所需的权限标识。以Spring Boot为例常见实现是自定义注解 拦截器Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequiresPermission { String value(); }然后写一个切面或拦截器在方法执行前取出注解中配置的权限标识和当前用户的权限集合做比对。比对时要注意超级管理员角色一般不逐条配置权限而是直接放行。这需要在校验逻辑中单独处理比如角色编码为admin时直接通过。权限校验还有几个容易被忽略的点接口路径中的参数如/order/123可能关联数据权限。不能只校验“登录用户能访问订单接口”还要校验“他能看这个订单吗”。这属于数据级权限RBAC模型只到接口级数据级需要额外判断归属、部门、区域等条件。校验顺序先认证再鉴权再数据过滤。认证未通过就返回401鉴权未通过返回403。这两个状态码经常用混但语义完全不同。权限配置的缓存问题。用户权限一旦变更应该立即让它生效而不是等缓存过期。常见做法是在权限变更时主动清理该用户的权限缓存。4.4 前端配合按钮级权限与动态路由前端权限有两个主要任务根据权限渲染菜单和按钮控制路由访问。菜单和路由可以合并处理登录后拿到用户的菜单列表和权限码集合动态生成可访问的路由表未配置权限的路由直接排除。按钮级权限的核心是“权限码控制”。后端接口返回用户拥有的按钮权限码列表如order:export、user:resetPwd前端在渲染按钮时判断v-permission指令或函数没权限就不渲染这个按钮。这里有个常见的体验矛盾按钮隐藏了但用户还是能通过手动调用接口实现操作。所以再次强调前端权限是纯体验优化后端必须做同等强度的校验。别以为前端把按钮藏起来权限就安全了这是大忌。5. 运维与排查实录权限认证系统的高频故障清单5.1 Token过期导致用户“莫名其妙”退出症状用户操作到一半刷新页面就跳回登录页尤其在做长表单填写时最恼火。排查后发现是Access Token的有效期设得太短比如30分钟用户填了半小时表单一提交Token就过期了。解决办法登录后签发Token时把过期时间设为2小时左右配合Refresh Token续期前端拦截HTTP 401响应静默用Refresh Token刷新并重放原请求。这个方案比单纯拉长过期时间更安全也比让用户频繁重新登录体验更好。踩坑提醒刷新Token的接口本身要防重放。客户端并发请求时多个请求同时收到401会同时触发刷新逻辑容易造成刷成多个新Token。前端的做法是做单例刷新即所有401请求共享同一个刷新Promise刷新完成后再批量重放。5.2 权限缓存导致角色变更不生效症状用户角色刚从“运营”改为“普通用户”但浏览器里还能访问运营菜单调运营接口也不报403。原因是权限数据在Redis里缓存了缓存过期时间还没到用户权限从旧缓存读取。解决办法角色变更、权限变更、用户禁用时主动删除该用户的权限缓存。可以用版本号方案用户权限缓存key带上版本号每次变更把版本号递增查询时按最新版本加载。这样既保留缓存性能又保证变更立即可见。5.3 分布式下JWT验证失败或Session丢失症状登录服务在A节点登录后第二个请求被负载均衡分发到B节点B节点验签失败或者Session找不到。JWT方案遇到这类问题大概率是各节点密钥不一致或时钟偏差导致时间校验不过。Session方案则是没有做集中存储。解决办法JWT的场景统一密钥管理和服务器时间同步Session场景把Session存Redis或采用粘性会话。生产环境下我建议宁可用JWT集中密钥管理也不要用粘性会话解决分布式问题因为粘性会话会导致负载不均衡。5.4 前端跳转死循环症状Token过期后前端Axios拦截器发现401跳转登录页而登录页本身也需要认证凭据于是来回跳转甚至死循环刷新。解决办法在全局拦截器里区分请求来源。登录接口、刷新Token接口不携带Token不做401跳转其它接口收到401才跳登录页。还需设置标志位避免多个401并发触发多次跳转。5.5 权限校验中的大小写不一致症状接口权限标识在数据库里存的是Order:Query代码里注解写的是order:query校验永远不通过。这个低级错误非常常见而且不好排查因为报错信息通常只是403不告诉你具体差在哪。解决办法权限标识统一小写加下划线或冒号分隔比如order:query、sys:user:delete数据库录入和代码编写都用同一套规范可以在单元测试里对所有接口的权限标识做一次合法性检查防止低级笔误。6. 权限设计的下一步数据权限、审计与安全强化6.1 数据权限接口能访问不等于数据能看全很多系统做到接口级权限就停了但数据权限问题会在业务上线后集中爆发。最典型的是销售数据两个销售都能访问订单列表接口但A销售不应该看到B销售的订单。数据权限如果不能下沉到查询层就只能靠前端做模糊后端一调用还是全量数据。数据权限的常见实现有两种一种是硬编码比如在SQL里强制拼接当前用户的部门ID、地区ID条件另一种是做规则引擎给角色配置数据范围全部、本部门、本部门及以下、本人查询时根据规则动态拼条件。前者简单直接后者灵活但复杂度高。我个人的建议是先用硬编码扛过前几个版本等真有多套数据范围规则的需求了再上规则引擎不要一开始就铺开。6.2 认证安全加固的几件实事权限认证系统本身就是攻击者最喜欢的目标。有几个安全加固动作投入不大但效果明显登录接口加验证码能挡住大批量密码撞库。登录失败次数限制比如连续失败5次锁定15分钟或者要求验证码。密码强度策略强制长度、字符种类定期提醒更换。敏感操作二次验证比如修改密码、导出数据、删除资源等操作要求重新输入密码或短信验证码。记录操作日志关键操作必须有操作人、时间、结果、IP、请求参数方便事后追溯。设置Token黑名单机制用户被禁用、密码修改后老Token要能及时失效。6.3 权限模型的演进路线从零开始做权限系统我建议按这个顺序走先做Session或JWT的登录认证再上RBAC角色权限先管菜单和接口再逐步加数据权限、操作审计。每一步都能独立上线生效不会一口气引入太多复杂度。如果系统已经成熟权限模块的演进方向通常是从角色权限扩展到用户组减少批量用户的管理成本。从单一角色扩展到多角色用户同时拥有多个角色的权限并集。从静态权限扩展到动态规则引入更多业务属性控制访问。从系统内权限扩展到统一认证中心支撑多系统单点登录。以我的经验权限体系最忌讳一步到位。某个大后台一开始就设计得又大又全角色、权限、数据范围、审批流全做进去结果项目上线后权限配置复杂到没有人敢动一个普通用户要配置半小时才能用。权限系统的目标不是“功能全”而是“够用且配置不费力”。7. 最后补充一点个人实践中的感受权限认证这块代码写起来不难难的是方案权衡和对细节的敬畏。见过很多系统登录做得挺顺权限注解也加了不少但一压测、一审计、一遇到数据越权需求问题就全都浮出来。核心还是要先把认证和授权这两件事分开想清楚认证管“是不是你”授权管“你能干什么”先保证认证可信再做授权的精细控制后端拦截是底线前端控制只是体验RBAC能解决的别急着上ABAC。如果你正在设计或者改造权限系统建议先画一张当前系统的请求链路图标出哪些地方做了认证、哪些地方做了授权、数据有没有被直接带出后端再决定下一步怎么动。很多时候问题不是缺某一项技术而是链条里某一环断掉了。理清了动起手来就不慌了。 
长河君 · 2026/10/15 23:04:28 · 阅读 1.2k 身份认证与权限授权全解析：从方案选型到落地实践
接手过不少系统第一件事先看登录和权限是怎么设计的。有些系统登录用的挺顺但换个角色就漏出各种权限洞有些系统权限控制得很严但每次登录过个十几分钟就掉线。这些问题的根源大多出在没搞清楚身份认证Authentication和权限授权Authorization这两件事上一个管“你是谁”一个管“你能干什么”。这两个概念看着简单实际落地时坑非常多而且一旦基础设计选型错了后面改起来基本等于重写。这篇就从核心原理、方案选型、落地实现到问题排查把权限认证这摊子事一次捋清楚希望对正在做登录鉴权、权限管理的朋友有点参考价值。不管你是刚接手老项目还是准备从零设计一套权限体系这篇的内容都适用。1. 先掰扯清楚认证和授权到底差在哪1.1 一个现实中的类比5分钟看懂两者关系很多人把认证和授权混着说面试时也经常听到“做一下权限认证”这种含糊的说法。但实际在系统里这是两个不同的环节必须严格区分。可以拿小区门禁来类比。进入小区大门时要刷门禁卡这张卡验证你是不是这个小区的住户这就是认证Authentication——证明“你是谁”。进了小区之后你能进A栋楼但进不了B栋楼因为B栋有独立门禁这就是授权Authorization——证明“你能干什么”。放到系统里认证解决的是“你是合法用户吗”常见手段有用户名密码、短信验证码、扫码登录、指纹、第三方登录等。认证通过后系统通常要给你发一个凭证相当于一张“通行卡”后续请求带着它系统才知道是“谁”在操作。授权解决的是“这个合法用户能操作哪些资源”常见手段有RBAC角色权限、ACL访问控制列表、ABAC属性权限等。授权发生在认证之后系统已经知道你是谁然后查一下规则判断你能不能访问这个接口、能不能看到这组数据、能不能点那个按钮。有个非常关键的次序问题认证在前授权在后。系统不可能对一个未认证的用户做授权校验因为根本不知道他是谁。但反过来也重要认证通过绝不代表能访问所有资源这是很多新手写代码时最容易犯的错——登录成功就直接放行全部接口认为用户已认证就等于有全部权限。1.2 术语拆解Authentication、Authorization 和 Authentication顺带把三个相关术语都理一下因为它们长得太像了不少人记混。Authentication身份认证验证用户身份确认“你声称你是的这个人确实是你”。核心是凭证校验。Authorization权限授权授予或验证用户对特定资源的操作权限关注的是“你有什么权利”。Identity / Account身份标识用户的唯一标识比如用户ID、用户名、手机号。认证的结果通常就是得到一个可信的标识。实际开发中它们三者的关系是这样的用户输入身份标识 凭证系统完成Authentication后拿着可信的身份标识去查询该标识对应的权限集合再对用户的每一次访问做Authorization校验。很多人只做了Authentication忽略了Authorization后果就是“登录后所有接口都能调”这在内部管理系统里尤其危险。1.3 常见误区登录成功不等于权限正确举一个我见过的真实案例。某后台系统A用户是普通运营B用户是管理员。代码里只做了登录拦截没有做管理员接口的权限控制。A用户手贱把浏览器的用户ID从100084改成100001管理员的ID再刷新页面竟然看到了管理员的全部菜单和数据。这就是典型的只做了Authentication没做Authorization身份可以被伪造或篡改权限完全失效。还有一个误区前端隐藏菜单就当做了权限控制。很多项目用Vue或React登录后根据角色动态渲染菜单没权限的菜单隐藏掉。但前端隐藏只是视觉层面的接口照样可以被直接调用。权限控制的底线必须放在后端前端只是在体验上做辅助。2. 身份认证方案选型Session、JWT、OAuth2到底选哪个2.1 Session认证适合传统单体、强服务端控制的场景Session认证是历史最悠久的方案。用户提交用户名密码服务端校验成功后生成一个Session记录存在服务端内存或Redis里同时把Session ID通过Cookie返回给浏览器。浏览器后续请求自动带上Cookie服务端根据Session ID查到对应的会话。Session方案最大的优点是可以随时在服务端销毁会话比如强制用户下线、封禁账号只需删除对应的Session记录就行。权限和会话状态都在服务端控制力最强。缺点是服务端要存状态集群部署时需要解决Session共享问题Cookie在跨域场景下比较麻烦移动端App要手动管理Cookie非常别扭。适用场景传统管理后台、单体应用、需要严格会话管控的系统。如果项目是经典的前后端一体开发Session依然是个可靠选择。2.2 JWT认证无状态是优点也是软肋JWTJSON Web Token是目前最流行的认证方案之一。认证成功后服务端签发一个包含用户标识、过期时间等信息的Token客户端存起来每次请求放到Header里。服务端不再保存会话状态校验时验签即可。JWT的最大优势是无状态天然支持分布式、水平扩展也不用存Session。但它有几个必须注意的软肋Token一旦签发在过期之前无法主动使其失效。用户被禁用了Token还是能继续用除非额外做黑名单机制这又回到了有状态的路上。Token体积比Session ID大不少请求头塞一个长字符串对网络带宽有点浪费。密钥管理要求高一旦密钥被泄露攻击者可以自己伪造Token整个认证体系形同虚设。适用场景前后端分离项目、小程序、App接口、微服务间认证。现在的用户中心、开放平台JWT基本是标配。2.3 OAuth2/SSO多系统、第三方登录的正确姿势当你的系统多了用户不希望在一个体系里注册N套账号于是有了SSO单点登录。SSO的核心是独立的认证中心多个业务系统共享一套登录态。OAuth2则是更通用的授权框架常用于第三方登录授权比如让用户用某个平台的账号登录你的系统。这里要提醒一下OAuth2不是认证协议它是授权协议。它的核心场景是“允许第三方应用代表用户访问资源”比如允许某个工具读取你的网盘文件列表。如果用OAuth2做单点登录还需要额外引入OpenID Connect这类身份认证层才能拿到用户身份信息。实际项目中有一些团队直接用OAuth2的Authorization Code流程实现单点登录逻辑上能跑通但理解上要清醒流程结束时你拿到的是Access Token还需要调用用户信息接口换取身份然后建立本地会话。2.4 选型建议总结我整理了一个自己的选型判断表格供参考场景类型推荐方案理由传统单体管理系统Session Cookie服务端可控强制下线方便技术成熟前后端分离后台JWT或Session存Redis避免跨域Cookie问题分布式友好纯API服务、小程序JWT无状态客户端集成简单多系统/多应用SSO认证中心统一登录态账号体系集中管理对接第三方登录OAuth2 OIDC标准协议避免自造轮子选择的标准不是“哪个新用哪个”而是看你的系统中“需要服务端主动失效会话吗”“跨域部署复杂吗”“客户端形态是什么”。这些问题想清楚了方案自然清晰。3. 权限授权模型RBAC、ABAC、ACL 应该怎么选3.1 RBAC角色权限模型管理后台的默认答案RBACRole-Based Access Control是目前运用最广泛的权限模型核心思路很简单用户不直接关联权限而是通过角色间接关联。比如“运营”角色拥有“订单查看、商品编辑”权限“管理员”角色拥有全部权限。RBAC的优点是模型直观、管理方便、适合权限相对稳定的系统。新增用户时只需给他分配角色不用一条一条配置权限。实际落地时通常有两种模式基础RBAC用户-角色-权限三级角色直接绑定权限。扩展RBAC增加用户组概念用户属于组组对应角色便于批量管理。设计数据库模型时通常涉及五张核心表用户表、角色表、权限表、用户角色关联表、角色权限关联表。有些系统还要加用户组表、用户组成员表。下面是一个典型的关系设计示例。-- 用户表 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY, username VARCHAR(64) UNIQUE, password VARCHAR(128), nickname VARCHAR(64) ); -- 角色表 CREATE TABLE sys_role ( id BIGINT PRIMARY KEY, role_code VARCHAR(64) UNIQUE, role_name VARCHAR(64) ); -- 权限表 CREATE TABLE sys_permission ( id BIGINT PRIMARY KEY, perm_code VARCHAR(64) UNIQUE, perm_name VARCHAR(64), type VARCHAR(16) -- menu/button/api/data ); -- 用户角色关联表 CREATE TABLE sys_user_role ( user_id BIGINT, role_id BIGINT, PRIMARY KEY (user_id, role_id) ); -- 角色权限关联表 CREATE TABLE sys_role_permission ( role_id BIGINT, permission_id BIGINT, PRIMARY KEY (role_id, permission_id) );这个结构看着简单但要注意权限表的type字段。开发时很容易只设计菜单权限把页面可见性当作全部权限最后发现接口权限、按钮权限、数据权限没地方放又得重建表。所以我建议一开始就把权限类型考虑进去区分菜单权限、操作权限、接口权限、数据权限为后面扩展留余地。3.2 ABAC属性权限模型复杂业务权限的解法RBAC的缺点是当权限规则非常复杂时角色数量会爆炸。比如“销售能看自己区域内的订单区域经理能看整个大区的订单财务专员能看所有已付款订单”这种规则如果全用角色表达角色列表会又长又难维护。ABACAttribute-Based Access Control是基于属性的权限模型。它把权限判断建立在主体属性、资源属性、环境条件之上。比如主体属性用户所属部门、职位级别、职级、所在地区。资源属性订单归属销售员、订单所属区域、订单状态。环境属性访问时间、登录IP、访问设备。授权策略不再是“角色A有权限B”而是“如果满足条件组合则允许访问”。比如一条策略可以写成允许 访问订单列表 当 订单.区域 用户.所属区域 且 订单.状态 in (已付款, 已发货)ABAC非常灵活但落地成本也高需要定义属性、规则引擎、策略管理界面。中小型项目直接上ABAC容易过度设计反而是给自己找麻烦。我的经验是大多数管理后台用RBAC就够了如果某些模块确实需要数据级权限可以局部引入数据权限规则而不是全系统上ABAC。3.3 ACL访问控制列表最原始也最直接ACLAccess Control List是最古老的授权模型直接在资源上列出“谁可以做什么”。比如文件系统里每个文件记录了哪个用户能读、哪个用户能写。ACL足够简单、精确但用户一多、资源一多维护ACL的成本会急剧上升。ACL在业务系统里较少作为主权限模型使用但在某些特定场景很合适比如文档系统的分享设置、网盘的文件权限、配置中心的某项配置针对特定用户开放。它常作为RBAC的补充解决“单个特例”的授权需求。3.4 权限模型选型的取舍用一句话总结我自己的选型经验能用RBAC解决的不要上ABACACL作为补充机制不要作为主模型。权限模型的复杂度应该跟业务复杂度匹配模型越复杂开发维护成本越高而且权限系统本身的bug越难排查。很多团队一上来就设计了个巨大的权限引擎结果半年后没人敢动那套代码——这就是过度设计。4. 从登录到鉴权核心流程设计与落地实操4.1 登录认证的标准流程拆解不管用Session还是JWT一个健壮的登录流程都包含以下几个环节凭证输入与传输用户名 密码务必通过HTTPS传输防止明文被抓包。参数校验先做基础校验用户名密码非空再做安全策略校验比如验证码、登录失败次数限制。密码校验从数据库读取用户信息用存储的哈希值验证明文密码。绝对不能用明文密码或可逆加密存储。状态检查确认用户状态是否正常未激活、被禁用、已删除的账号不能登录。签发凭证生成Session或JWT记录登录信息。记录日志记录登录成功/失败时间、IP、设备信息便于安全审计。这里重点强调密码存储。用MD5直接存密码早就过时了正确做法是用bcrypt、scrypt或argon2这类专门设计的密码哈希算法。bcrypt的优势在于它内部自带盐且可以调整计算成本参数同一密码每次生成的哈希都不一样还能抵御暴力破解。推荐直接使用成熟的库比如Java的jBCrypt、Node的bcryptjs、Python的bcrypt。一个典型的用户密码存储流程是注册时生成哈希后写入数据库登录时将用户输入明文与数据库中的哈希做校验。尽量少自己写加密算法这是花式踩坑的重灾区。我见过有同事把用户密码按字符做了一个简单的替换表之后就存进数据库表面上看是“加密了”实际上一个正则工具就能还原出来。存储密码的哈希不是给黑客准备的是给你自己的系统兜底的。一旦数据库泄露密码哈希不能直接被还原成明文用户在其他平台的密码也不会受到牵连。4.2 JWT的签发、刷新与安全注意点用JWT做主认证时Token策略设计得当能解决很多后续麻烦。一个标准的JWT包含Header、Payload、Signature三部分Payload里一般放用户ID、登录时间、过期时间等非敏感信息签名部分由服务端密钥生成。签发Token时我建议把过期时间设短一点比如2小时然后用一个Refresh Token刷新令牌来续期。Refresh Token过期时间可以长些比如7天或14天。客户端在Access Token即将过期时拿Refresh Token换取新的Access Token。这样即使Access Token泄露攻击者的利用窗口也被压缩了。一个常见的坑是Refresh Token没有做失效控制既不存服务端也不做版本号用户修改密码后旧Refresh Token还能继续换新Token。解决方法是给Refresh Token加版本号或者存Redis每次换新时校验版本密码修改时版本号加1旧令牌全部作废。密钥管理方面JWT的签名密钥要放进环境变量或配置中心不要写死在代码库。一旦怀疑密钥泄露需要立即更换密钥并让所有用户重新登录。如果分布式部署各节点必须使用同一个密钥或同一个公钥/私钥对否则会出现“这个节点签发的Token另一个节点验证失败”的问题。下面是一段典型的JWT校验中间件逻辑Java为例逻辑表达与语言无关public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) { String token extractTokenFromHeader(request); if (token null || token.isEmpty()) { throw new UnauthorizedException(缺少Token); } try { Claims claims Jwts.parserBuilder() .setSigningKey(secretKey) .build() .parseClaimsJws(token) .getBody(); request.setAttribute(userId, claims.get(userId)); // 还可从库里加载用户最新状态做额外的失效校验 } catch (JwtException e) { throw new UnauthorizedException(Token无效或已过期); } chain.doFilter(request, response); }注意上面只完成了Authentication即“这个请求是谁发出的”。接下来的Authorization校验还需要一层权限过滤器判断该用户是否有权限访问此接口。经常有团队把两件事放在一个过滤器里或者只做前者不做后者结果就是认证通过后访问任意接口都畅通无阻。4.3 后端权限拦截如何设计接口级权限校验接口级权限校验通常的做法是给每个接口定义一个权限标识比如order:query、order:update、user:delete然后通过注解或配置绑定到接口上。用户登录后系统加载该用户拥有的全部权限标识在请求到达接口前校验当前用户的权限集合中是否包含该接口所需的权限标识。以Spring Boot为例常见实现是自定义注解 拦截器Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface RequiresPermission { String value(); }然后写一个切面或拦截器在方法执行前取出注解中配置的权限标识和当前用户的权限集合做比对。比对时要注意超级管理员角色一般不逐条配置权限而是直接放行。这需要在校验逻辑中单独处理比如角色编码为admin时直接通过。权限校验还有几个容易被忽略的点接口路径中的参数如/order/123可能关联数据权限。不能只校验“登录用户能访问订单接口”还要校验“他能看这个订单吗”。这属于数据级权限RBAC模型只到接口级数据级需要额外判断归属、部门、区域等条件。校验顺序先认证再鉴权再数据过滤。认证未通过就返回401鉴权未通过返回403。这两个状态码经常用混但语义完全不同。权限配置的缓存问题。用户权限一旦变更应该立即让它生效而不是等缓存过期。常见做法是在权限变更时主动清理该用户的权限缓存。4.4 前端配合按钮级权限与动态路由前端权限有两个主要任务根据权限渲染菜单和按钮控制路由访问。菜单和路由可以合并处理登录后拿到用户的菜单列表和权限码集合动态生成可访问的路由表未配置权限的路由直接排除。按钮级权限的核心是“权限码控制”。后端接口返回用户拥有的按钮权限码列表如order:export、user:resetPwd前端在渲染按钮时判断v-permission指令或函数没权限就不渲染这个按钮。这里有个常见的体验矛盾按钮隐藏了但用户还是能通过手动调用接口实现操作。所以再次强调前端权限是纯体验优化后端必须做同等强度的校验。别以为前端把按钮藏起来权限就安全了这是大忌。5. 运维与排查实录权限认证系统的高频故障清单5.1 Token过期导致用户“莫名其妙”退出症状用户操作到一半刷新页面就跳回登录页尤其在做长表单填写时最恼火。排查后发现是Access Token的有效期设得太短比如30分钟用户填了半小时表单一提交Token就过期了。解决办法登录后签发Token时把过期时间设为2小时左右配合Refresh Token续期前端拦截HTTP 401响应静默用Refresh Token刷新并重放原请求。这个方案比单纯拉长过期时间更安全也比让用户频繁重新登录体验更好。踩坑提醒刷新Token的接口本身要防重放。客户端并发请求时多个请求同时收到401会同时触发刷新逻辑容易造成刷成多个新Token。前端的做法是做单例刷新即所有401请求共享同一个刷新Promise刷新完成后再批量重放。5.2 权限缓存导致角色变更不生效症状用户角色刚从“运营”改为“普通用户”但浏览器里还能访问运营菜单调运营接口也不报403。原因是权限数据在Redis里缓存了缓存过期时间还没到用户权限从旧缓存读取。解决办法角色变更、权限变更、用户禁用时主动删除该用户的权限缓存。可以用版本号方案用户权限缓存key带上版本号每次变更把版本号递增查询时按最新版本加载。这样既保留缓存性能又保证变更立即可见。5.3 分布式下JWT验证失败或Session丢失症状登录服务在A节点登录后第二个请求被负载均衡分发到B节点B节点验签失败或者Session找不到。JWT方案遇到这类问题大概率是各节点密钥不一致或时钟偏差导致时间校验不过。Session方案则是没有做集中存储。解决办法JWT的场景统一密钥管理和服务器时间同步Session场景把Session存Redis或采用粘性会话。生产环境下我建议宁可用JWT集中密钥管理也不要用粘性会话解决分布式问题因为粘性会话会导致负载不均衡。5.4 前端跳转死循环症状Token过期后前端Axios拦截器发现401跳转登录页而登录页本身也需要认证凭据于是来回跳转甚至死循环刷新。解决办法在全局拦截器里区分请求来源。登录接口、刷新Token接口不携带Token不做401跳转其它接口收到401才跳登录页。还需设置标志位避免多个401并发触发多次跳转。5.5 权限校验中的大小写不一致症状接口权限标识在数据库里存的是Order:Query代码里注解写的是order:query校验永远不通过。这个低级错误非常常见而且不好排查因为报错信息通常只是403不告诉你具体差在哪。解决办法权限标识统一小写加下划线或冒号分隔比如order:query、sys:user:delete数据库录入和代码编写都用同一套规范可以在单元测试里对所有接口的权限标识做一次合法性检查防止低级笔误。6. 权限设计的下一步数据权限、审计与安全强化6.1 数据权限接口能访问不等于数据能看全很多系统做到接口级权限就停了但数据权限问题会在业务上线后集中爆发。最典型的是销售数据两个销售都能访问订单列表接口但A销售不应该看到B销售的订单。数据权限如果不能下沉到查询层就只能靠前端做模糊后端一调用还是全量数据。数据权限的常见实现有两种一种是硬编码比如在SQL里强制拼接当前用户的部门ID、地区ID条件另一种是做规则引擎给角色配置数据范围全部、本部门、本部门及以下、本人查询时根据规则动态拼条件。前者简单直接后者灵活但复杂度高。我个人的建议是先用硬编码扛过前几个版本等真有多套数据范围规则的需求了再上规则引擎不要一开始就铺开。6.2 认证安全加固的几件实事权限认证系统本身就是攻击者最喜欢的目标。有几个安全加固动作投入不大但效果明显登录接口加验证码能挡住大批量密码撞库。登录失败次数限制比如连续失败5次锁定15分钟或者要求验证码。密码强度策略强制长度、字符种类定期提醒更换。敏感操作二次验证比如修改密码、导出数据、删除资源等操作要求重新输入密码或短信验证码。记录操作日志关键操作必须有操作人、时间、结果、IP、请求参数方便事后追溯。设置Token黑名单机制用户被禁用、密码修改后老Token要能及时失效。6.3 权限模型的演进路线从零开始做权限系统我建议按这个顺序走先做Session或JWT的登录认证再上RBAC角色权限先管菜单和接口再逐步加数据权限、操作审计。每一步都能独立上线生效不会一口气引入太多复杂度。如果系统已经成熟权限模块的演进方向通常是从角色权限扩展到用户组减少批量用户的管理成本。从单一角色扩展到多角色用户同时拥有多个角色的权限并集。从静态权限扩展到动态规则引入更多业务属性控制访问。从系统内权限扩展到统一认证中心支撑多系统单点登录。以我的经验权限体系最忌讳一步到位。某个大后台一开始就设计得又大又全角色、权限、数据范围、审批流全做进去结果项目上线后权限配置复杂到没有人敢动一个普通用户要配置半小时才能用。权限系统的目标不是“功能全”而是“够用且配置不费力”。7. 最后补充一点个人实践中的感受权限认证这块代码写起来不难难的是方案权衡和对细节的敬畏。见过很多系统登录做得挺顺权限注解也加了不少但一压测、一审计、一遇到数据越权需求问题就全都浮出来。核心还是要先把认证和授权这两件事分开想清楚认证管“是不是你”授权管“你能干什么”先保证认证可信再做授权的精细控制后端拦截是底线前端控制只是体验RBAC能解决的别急着上ABAC。如果你正在设计或者改造权限系统建议先画一张当前系统的请求链路图标出哪些地方做了认证、哪些地方做了授权、数据有没有被直接带出后端再决定下一步怎么动。很多时候问题不是缺某一项技术而是链条里某一环断掉了。理清了动起手来就不慌了。