场景

一个用户成功登录，并不代表他可以读取任意订单。把认证与授权混在控制器里，会导致重复代码和越权漏洞。

原理

认证验证主体身份，授权依据主体、动作、资源和环境做决策。Cookie 是浏览器保存并自动发送的数据，Session 是服务端会话状态；JWT 是可签名的声明载体。OAuth 2.0 处理委托授权，SSO 则让多个应用复用统一登录状态。

设计步骤

先定义身份源和登录强度；再选择 Session 或令牌并设计过期、续期、注销；将授权放在资源访问前且服务端执行；集群 Session 使用共享存储或一致路由；跨站请求配置 CSRF、防重放和 Cookie 安全属性。

权衡

Session 易撤销且载荷小，但水平扩展需要共享状态；JWT 验证本地化，却有撤销与体积成本。RBAC 管理直观，面对资源属性和上下文时可能需要 ABAC。SSO 改善体验，也扩大身份中心故障影响。

实践建议

401 表示尚未有效认证，403 表示身份明确但无权限。认证结果只提供主体，不替代对象级授权。会话 ID 必须随机并在登录后轮换；敏感操作重新认证。审计记录谁在何时对何资源执行何动作，同时避免写入凭证本身。

落地检查

上线前还应做一次桌面演练：准备正常、边界、超时、重复与恶意输入，确认系统的返回、日志和指标彼此对应；在预发布环境模拟依赖不可用、进程重启和配置回滚，验证降级路径不会放大故障。上线时采用小流量观察，提前定义停止条件与负责人。稳定后复盘真实数据，删除没有收益的复杂度，并把新发现的约束补进测试、监控和设计记录，使方案能够随业务持续演进，而不是停留在一次性评审结论。