参考文档

0. 经典 SSO 时序图

1. 结合 OAuth 2.0 授权机制的 SSO 实现

  • SSO 核心功能是「认证」，「认证中心」去判断访客身份声明的有效性，然后告诉应用服务当前访客的身份信息以便应用为访客提供服务
  • 核心认证数据（如账号密码）存放于认证中心（即 SSO 服务），应用无需也无权读取或存放核心认证数据；访客通过认证后，应用根据访客 ID 为其提供服务
  • 若应用仅需验证访客 ID 有效性，或仅展示当前访客的基本信息，简单的 SSO 的实现已经可以满足
  • 用户授权给应用（尤其是第三方应用）通常会限定一个有效期，有效期过后，应用不能再向「授权中心」请求客户信息
  • OAuth 2.0 是一种授权机制，非常适用于上述「授权中心」所处的业务场景，使得各应用能基于用户授权为用户提供功能服务

2. 一些考虑

2.1 为什么不使用反向代理

在访问抵达应用前，可以由一层反向代理作验证服务，为什么不采用这种方式？

  • 该反向代理服务相当于一个接入 SSO 的应用，不在 SSO 设计的范畴中
  • 反向代理有局限性，虽然解决了认证的问题，但并未解决「授权」的问题，上游应用获取客户信息并不方便
  • 应用服务数量多，分布广，性能要求各异，全局性的反向代理服务很难实现，通常由业务内容及协作密切的一组应用去自行实现其所需的反向代理服务

2.2 为什么要用 OAuth

为什么要用 OAuth，直接用简单的 SSO 登录然后获取应用信息不就好了？

  • 若应用仅需验证访客 ID 有效性，或仅展示当前访客的基本非敏感信息，简单 SSO 的实现的确已经可以满足
  • 当应用对客户信息及其他资源的需求范围扩大，应用数量增加，系统不可避免地需要实现分级授权（当前已经处于此阶段），而 OAuth 2.0 便是一种典型的授权实现方式

2.3 登录状态

  • 建议应用将标识登录状态的 Cookie 有效期设置为 session 级别，作用域为应用专属的子域名而非一级域名