项目如何实现用户鉴权与接口访问权限控制？

核心回答

项目中的鉴权应分成身份认证、接口授权和数据权限三层：先确认请求是谁发起的，再判断他能执行什么操作，最后校验他是否有权操作这条具体数据。Token 有效只解决第一层，不代表可以访问所有接口和所有人的数据。

以 Spring Security 6.5 的 Servlet 应用、Bearer JWT 为参考方案，请求流程可以这样组织：

1. 登录与凭证：登录端验证凭据后签发有明确有效期和用途的令牌；客户端通过 HTTPS 携带令牌访问后端。也可以采用服务端 Session，凭证形式按项目选择。
2. 统一认证：安全过滤器链提取令牌，使用可信密钥和允许的算法校验签名，并校验有效期、签发方、接收方等适用条件，构造当前用户的 Authentication，放入 SecurityContext。
3. 接口和方法授权：按路径、HTTP 方法配置访问规则；业务方法可以声明所需权限。用户、角色、权限之间的关系由后端维护，不信任前端传来的角色或权限列表。
4. 资源范围校验：访问订单、文件等对象时，还要核对当前用户、租户与资源的归属关系，在查询或业务操作中落实范围限制。只通过“订单查询权限”，不等于能查询任意订单。

公开接口应明确放行，其余入口按规则拒绝未获授权的访问。前端隐藏菜单或按钮可以改善体验，后端仍然要执行访问控制。

进一步解释

“给 Controller 加注解”之后，权限检查怎样生效？

注解只声明规则，还需要框架的拦截机制执行。以方法授权为例，需要启用 @EnableMethodSecurity；Spring Boot 的 Security Starter 并不会默认启用方法授权。

在配置好用户权限到 GrantedAuthority 的映射后，可以用 @PreAuthorize("hasAuthority('order:read')") 声明方法所需权限。框架在被代理的方法执行前，从当前 Authentication 取得身份与权限，评估表达式；不满足就拒绝调用。

权限名称要与映射约定一致。OAuth scope 默认映射为带 SCOPE_ 前缀的 authority，不能一边保留默认映射，一边用另一个名称检查。默认代理模式下，同类内部调用也可能绕过方法拦截，因此关键授权应放在真实经过拦截的入口，并在业务层继续落实资源范围。

RBAC 与数据权限怎样配合？

RBAC 通常维护用户、角色、权限，以及用户角色、角色权限的关联。例如客服角色拥有 order:read，管理员另外拥有管理权限。角色用于集中管理权限，接口检查具体的操作权限。

但 RBAC 本身并没有回答“这张订单属于谁”。参考设计中，普通用户查询订单时，需要把当前可信用户 ID 与订单 ID 一起作为查询条件；多租户场景还要加入租户范围。管理员跨范围访问则需要单独授权，而不是让前端随意传一个 userId 或 tenantId 决定范围。

列表、导出、下载和更新同样要执行这些检查，不能只保护详情页。随机或难猜的资源 ID 有帮助，但不替代授权。

JWT 验证为什么不能只做解析？

JWT 的 Header 和 Payload 通常可以直接解码。能读出 userId，并不证明这个字段可信；普通签名 JWT 也没有自动加密其中的内容。

服务端应通过成熟实现验证签名和适用声明，固定可信的算法与密钥来源，再建立用户上下文。接收方校验也需要按系统要求配置，不能假定只设置 issuer 就自动满足全部业务验证。

对于有即时封禁、退出登录或权限回收要求的系统，还要设计撤销机制，例如服务端会话、令牌版本检查或撤销记录；短有效期只能缩小旧权限窗口，不能保证立即失效。把权限放进 JWT 后，也要考虑它在有效期内可能已经过时。

常见追问

网关做过鉴权，业务服务还需要检查吗？

网关适合统一做入口认证和粗粒度规则，但订单归属、数据状态等通常只有业务服务掌握。服务还要确保接收到的是可信身份上下文，不能任意信任外部可伪造的用户头。能绕过网关直连服务的路径，也必须受到保护。

没有登录和没有权限，怎么区分？

API 通常用 401 表示缺少或无效的认证凭证，用 403 表示身份已确认但不允许相应操作；还应结合协议和资源隐藏策略统一响应。后端日志记录必要的身份、资源、动作和拒绝原因，避免把完整令牌或敏感凭据写入日志。

用了 JWT 或无状态接口，就不用防 CSRF 吗？

不能只看令牌格式。关键在于浏览器是否会自动附带凭证，例如 Cookie。若依赖这类自动携带的凭证，仍要配置适用的 CSRF 防护；令牌保存方式也需要兼顾 XSS 等风险。

参考资料