前言

用户与权限是企业系统的基础能力。面试里经常问：

  • 登录状态怎么保持。
  • Token 和 Session 有什么区别。
  • RBAC 怎么设计。
  • 菜单权限、按钮权限、接口权限怎么统一。
  • 单点登录怎么做。
  • 风控和验证码什么时候介入。

这类题目考的不是背定义，而是你能不能把“身份认证、权限授权、风控拦截、会话管理”这四件事拆清楚。

登录系统的基本链路

sequenceDiagram
    participant U as 用户
    participant G as 网关
    participant A as 认证服务
    participant R as Redis
    participant S as 业务服务

    U->>G: 登录请求
    G->>A: 转发用户名密码/验证码
    A->>A: 校验账号与风控
    A->>R: 写入会话或 Token 黑名单
    A-->>U: 返回 Token
    U->>G: 携带 Token 访问业务
    G->>S: 鉴权通过后转发

企业里的登录系统一般不只是“用户名密码校验”，还会加：

  • 验证码。
  • 短信/邮箱 OTP。
  • 设备指纹。
  • 登录失败次数限制。
  • 异常 IP 风控。
  • Token 刷新和注销。

Session 和 Token

Session 方案

登录成功后，服务端保存会话，客户端保存 SessionId。

优点：

  • 服务端可控。
  • 注销方便。
  • 传统系统实现简单。

缺点：

  • 分布式部署时要做 Session 共享或粘性会话。
  • 扩容麻烦。

适合：

  • 传统后台系统。
  • 浏览器为主的应用。

Token 方案

登录成功后，服务端签发 Token，客户端每次请求携带 Token。

优点：

  • 服务端无状态或弱状态。
  • 适合微服务和移动端。
  • 扩展性好。

缺点：

  • 注销和失效管理更复杂。
  • Token 泄漏风险更高。

适合：

  • 前后端分离。
  • 多端接入。
  • 微服务体系。

对比

方案 优点 缺点 适合场景
Session 简单、直观、易注销 分布式共享复杂 传统 Web
Token 无状态、扩展性好 失效管理复杂 API、移动端、微服务

面试回答建议：

小系统或传统 Web 用 Session 足够；前后端分离和微服务更常用 Token。真正落地时常常是 Token + Redis 做登录态管理和黑名单控制。

JWT 怎么看

JWT 是一种 Token 载体格式，常用于承载用户身份和权限声明。

优点：

  • 自包含。
  • 可跨服务传递。
  • 验签后可快速识别身份。

缺点：

  • 一旦签发不易主动失效。
  • Payload 不能放敏感信息。
  • 过大时会增加网络开销。

常见面试追问：

  • JWT 里可以放什么：用户 ID、角色、过期时间、设备标识等。
  • JWT 能否放密码：不能。
  • JWT 是否绝对安全：不是，仍然需要 HTTPS、密钥轮换、黑名单和过期控制。

RBAC 怎么设计

RBAC 是最常见的企业权限模型。

核心实体：

  • 用户 User。
  • 角色 Role。
  • 权限 Permission。
  • 菜单 Menu。
  • 资源 Resource。

关系：

  • 用户拥有多个角色。
  • 角色拥有多个权限。
  • 权限可以映射到菜单、按钮、接口。
flowchart TD
    U[用户] --> UR[用户-角色]
    UR --> R[角色]
    R --> RP[角色-权限]
    RP --> P[权限]
    P --> M[菜单/按钮/接口]

方案一：角色直接控制权限

简单，适合中小系统。

缺点：

  • 细粒度不够灵活。

方案二：角色 + 权限码

每个按钮、接口、页面功能都有统一权限码。

优点：

  • 细粒度控制。
  • 后台、前端、网关可以共享权限码。

适合：

  • 企业后台。
  • 多系统统一权限中心。

方案三：RBAC + 数据权限

除了功能权限，还要控制数据范围，例如：

  • 只能看自己部门数据。
  • 只能看自己负责的客户。
  • 区域代理只能看本区域订单。

这是企业里更常见的复杂权限模型。

菜单权限、按钮权限、接口权限

权限往往不是只做接口拦截。

权限类型 作用位置 示例
菜单权限 前端导航 是否展示“退款管理”菜单
按钮权限 页面操作 是否显示“审核”“删除”按钮
接口权限 服务端网关/拦截器 是否允许调用 /refund/approve
数据权限 SQL 层/业务层 是否只能查本部门订单

面试重点：

  • 前端隐藏按钮不是安全控制，安全必须在后端做。
  • 只做前端权限不够。
  • 接口权限和数据权限要分开设计。

单点登录怎么做

企业常见多个系统共用一套身份中心。

常见方案：

  1. 统一认证中心 + Session。
  2. 统一认证中心 + JWT。
  3. OAuth2 / OIDC。

对比：

方案 优点 缺点
统一 Session 简单直观 分布式共享复杂
JWT SSO 扩展性好 注销和失效管理麻烦
OAuth2/OIDC 标准化、适合第三方接入 接入复杂度高

面试时可以强调：

企业内多个系统共享登录态时，通常会有统一认证中心。认证中心负责登录和发证，业务系统只验证 Token 或票据，不直接接触密码。

风控怎么做

风控不是只靠验证码。

常见风险：

  • 频繁登录失败。
  • 短时间多地登录。
  • 设备切换异常。
  • 批量注册。
  • 接口刷单。
  • 异常 IP 和代理流量。

常见措施：

  • 图形验证码。
  • 短信验证码。
  • 登录失败次数限制。
  • 设备指纹。
  • IP 频率限制。
  • 黑名单/白名单。
  • 登录地异常提醒。
flowchart TD
    A[登录请求] --> B{是否异常}
    B -->|正常| C[正常登录]
    B -->|高风险| D[验证码/短信验证]
    B -->|高危| E[拒绝登录或人工审核]

权限校验放在哪里

常见放置位置：

  • 网关层：粗粒度鉴权。
  • 认证服务：统一登录和 Token 校验。
  • 业务服务拦截器：接口级权限。
  • Service 层：业务约束和数据权限。
  • SQL 层：复杂数据权限过滤。

一般建议：

  • 网关做统一身份识别。
  • 业务服务做细粒度权限。
  • 数据权限尽量靠近查询层。

常见高频题

Token 为什么要过期？

因为 Token 一旦泄漏就可能被长期滥用。过期时间可以缩短泄漏窗口，配合刷新 Token、黑名单和重新登录机制更安全。

JWT 为什么不能只靠签名就永久有效？

因为签名只能证明内容没被篡改，不能证明这个身份已经被主动注销。要结合过期、黑名单和刷新机制。

为什么前端隐藏按钮还要后端校验？

前端可以被绕过，后端才是最终安全边界。

权限码怎么设计更稳妥？

建议采用统一命名规则，例如 order:refund:approve，前后端、网关、服务端统一使用。

数据权限和功能权限有什么区别？

功能权限控制“能不能做”，数据权限控制“能看到哪部分数据”。

总结

用户与权限场景回答可以围绕四条主线：

  1. 认证怎么做：Session、Token、JWT、SSO。
  2. 授权怎么做：RBAC、权限码、数据权限。
  3. 安全怎么做：验证码、风控、黑名单、失效控制。
  4. 多系统怎么协同：认证中心、网关、业务服务、统一权限中心。

企业里真正稳的方案通常不是单一技术，而是认证中心 + Token/Session + RBAC + 风控 + 数据权限的组合。