后端面试里，如果简历写了登录、权限或网关，很容易被追问：JWT 和 Session 有什么区别？网关鉴权做什么？权限校验放网关还是业务服务？如果回答只停在“JWT 无状态，Session 有状态”，很难体现工程能力。
鉴权系统真正要解决的是身份、权限和动作边界。身份回答“你是谁”，权限回答“你能看什么”，业务授权回答“你在当前状态下能不能做这件事”。这三件事不能混在一起。
网关适合做统一身份验证
网关适合处理通用逻辑：校验 token 是否存在、签名是否可信、是否过期、是否属于当前系统，解析出用户身份和租户信息，再把可信身份传给后端服务。这样每个服务不用重复处理基础认证细节。
但网关不适合判断所有业务权限。比如订单是否属于当前用户、合同是否已经归档、审批节点是否轮到这个人处理，这些都需要业务数据支持，必须放到业务服务里判断。网关最多做粗粒度拦截，不能替代业务授权。
JWT 的优势和代价
JWT 常被说成无状态，但无状态不是只有好处。它减少了服务端会话查询压力，也方便跨服务传递身份信息；代价是撤销和状态变更更难。用户修改密码、账号禁用、角色变化后，已经签发的 token 可能还在有效期内。
因此 JWT 需要配合过期时间、刷新机制、黑名单或版本号。企业系统里常见做法是 token 短有效期，刷新 token 更长有效期；关键权限变更时更新用户权限版本，让旧 token 失效。不要把 JWT 当成永远不用查库的万能方案。
权限要分层
权限通常至少有三层。第一层是接口级权限，判断用户是否能访问某个 API。第二层是数据级权限，判断用户能看哪些组织、项目、客户或文档。第三层是动作级权限，判断当前业务状态是否允许这个动作。
例如用户有“订单管理”权限，不代表能取消任何订单；他可能只能管理自己部门的订单，也只能取消待支付或待发货状态的订单。面试里能把这三层拆开，比只说 RBAC 更成熟。
安全还要看失败路径
鉴权失败时，不要泄露过多信息。告诉用户 token 无效、权限不足或资源不存在，要根据场景谨慎设计。对外系统尤其要避免通过错误信息暴露资源是否存在。
高风险动作还应该有二次确认和审计。比如删除、退款、取消、导出数据，不能因为用户已登录就直接执行。鉴权的终点不是接口放行，而是每个业务动作都有身份、权限、状态和审计闭环。
还有一个常见误区，是把“前端隐藏按钮”当成权限控制。前端可以优化体验，但不能作为安全边界。用户即使看不到按钮，也可能直接调用接口；后端必须重新验证身份、数据范围和动作权限。
如果面试官继续追问多租户系统，可以补充租户隔离。用户身份里要带租户或组织上下文，查询和写入都必须带上租户条件，缓存键也要包含租户维度。否则权限逻辑写对了，缓存或查询漏了租户，仍然会造成越权。