常见三种单点登录方案

 

SESSION+COOKIE模式

• ​机制​：
  1. 用户进行登录操作，向认证中心发送登录请求。
  2. 认证中心验证用户信息通过后，创建并存储会话状态（Session），并为该Session生成唯一的Session ID。
  3. 认证中心通过Set - Cookie将包含Session ID的Cookie发送给客户端。
  4. 客户端后续请求受保护的资源时，自动携带包含Session ID的Cookie。
  5. 子系统A（如其他需要认证的系统）接收到请求后，将Cookie中的Session ID发送给认证中心进行验证。
  6. 认证中心验证Session ID是否有效。
  7. 如果有效，子系统A返回受保护的资源给客户端。
• ​优缺点​：
  • ​优点​：服务端完全掌控会话，可以即时撤销会话，安全性较高。
  • ​缺点​：由于服务端存储了Session状态，扩展性较差，需要共享存储来保证不同服务器间Session的一致性；同时存在跨站请求伪造（CSRF）风险，因为Cookie会被自动携带。

TOKEN模式

• ​机制​：
  1. 用户向认证中心发起登录请求。
  2. 认证中心验证通过后，签发一个包含用户信息和签名的Token给客户端。
  3. 客户端后续请求受保护的资源时，在请求头（通常是Authorization头）中主动携带此Token。
  4. 子系统A接收到请求后，验证Token的签名和有效期等信息，确认用户身份。
• ​优缺点​：
  • ​优点​：无状态，天生支持分布式扩展，因为服务端不需要存储会话状态，只需要验证Token的有效性。
  • ​缺点​：Token难以即时撤销，一旦签发，在有效期内就一直有效，除非过期；过期后用户需要重新登录获取新的Token。

TOKEN+REFRESHTOKEN模式

• ​机制​：
  1. 用户登录成功后，服务端同时签发两个令牌：短期有效的AccessToken（如有效期15分钟）和长期有效的RefreshToken（如有效期7天）。
  2. 客户端使用AccessToken访问受保护资源，每次请求时在请求头中携带AccessToken。
  3. 当AccessToken过期时，客户端使用RefreshToken向服务端的专用接口申请新的AccessToken。
  4. 服务端验证RefreshToken的有效性（包括状态、是否吊销等），如果有效则签发新的AccessToken（也可以选择签发新的RefreshToken）并返回给客户端。
• ​优缺点​：
  • ​优点​：无状态的AccessToken保障了分布式扩展性；服务端可控的RefreshToken可以实现会话的即时吊销与安全续期，静默刷新机制可以大幅提升用户体验，即在AccessToken过期时自动使用RefreshToken获取新的AccessToken，用户无感知。
  • ​缺点​：实现复杂度显著增加，需要维护RefreshToken的存储（如数据库）并关联用户；同时刷新接口面临跨站请求伪造（CSRF）与暴力破解攻击风险，因为RefreshToken是很重要的凭证，需要做好安全防护。

这些模式在不同的应用场景中有着各自的优势和适用情况，开发者可以根据项目的具体需求，如安全性要求、分布式扩展需求、用户体验需求等来选择合适的认证授权模式。