Session、JWT、OAuth 2.0 与 OIDC：登录、认证和授权别再混用

登录是用户证明身份的过程，认证是系统确认“你是谁”，授权是判断“你能做什么”。Session、JWT 和 OAuth 2.0 也不在同一个比较维度：前两者常用于保存或携带登录状态，OAuth 2.0 是委托授权框架。

用户提交凭证
  -> 服务端验证
  -> 创建 Session 并存入服务端或 Redis
  -> 返回只含 Session ID 的 Cookie
  -> 后续请求携带 Cookie
  -> 服务端查 Session 并执行授权

Cookie 应设置 HttpOnly、Secure 和合适的 SameSite。Session 易于主动注销和服务端撤销，但多实例部署需要共享存储或稳定路由。

JWT 的签名与验证

JWT 常见结构是 header.payload.signature。Payload 只是 Base64URL 编码，默认并未加密，不应放密码和隐私数据。

1 2	签发：Header + Claims -> 使用密钥签名 -> 返回 Token 验证：解析 Token -> 验证签名 -> 检查 exp、iss、aud 等声明

对称算法由签发和验证方共享同一密钥；非对称算法用私钥签名、公钥验证。私钥不传给客户端，公钥可以通过受控方式分发给验证服务。

Refresh Token 泄露风险更高，应安全存储、支持轮换和撤销。JWT 无状态是指资源服务可仅凭 Token 和验证材料完成认证，不代表系统完全没有用户、权限或撤销状态。

OAuth 2.0 解决“允许某个客户端代表资源所有者访问受限资源”；OIDC 在 OAuth 2.0 之上增加身份层，提供登录和 ID Token 等约定。

用户 -> 授权服务器登录与同意
客户端 <- 获得授权码
客户端 -> 用授权码换 Token
客户端 -> 携带 Access Token 访问资源服务器

浏览器和移动应用通常使用 Authorization Code + PKCE。不要自己发明第三方登录流程，也不要把 Access Token 当作永久用户会话。

认证成功只说明身份可信。读取订单时仍要检查角色、资源归属、租户和操作范围：

1	Token 有效 + order.user_id == current_user.id

后台管理员也应按最小权限授权，关键操作保留审计日志。