单点登录SSO与OAuth2 方案

1. SSO与OAuth2

单点登录系统 Single sign-on (SSO) ： 简单来说也就是一个在登录一个系统后不需要在重复登录其他系统的一种设计思想，其中较为著名的实现时CAS系统。

OAuth2：是一个开放标准，该标准约束了一种用户让第三应用访问用户在某一个应用中的资源而无需提供用户名和密码的方式，简单来说就是一个3方应用认证和访问用户资源的一种较为规范的流程方法。

SSO 与 OAuth2没有什么可比性，SSO是一种设计思想，OAuth2是一种具体资源认证授权的协议。

我们可以设计一种机制，来实现单点登录系统，采用OAuth2协议来做用户身份认证。

2. 融合

单点登录的设计思想如下所示：

简单来说就是用一个账号登录可以登录访问所有对接的系统，用户在认证进入单点登录系统后访问其他应用不需要再次认证。

OAuth2的授权码 授权码模式，提供了一种较为安全的访问用户资源的方式，该方式需要从被登录系统中通过连接跳转到登录系统，然后通过认证和授权，再有应用系统通过Token获取用户信息，若对OAuth不熟悉的可以参考 《理解OAuth 2.0 阮一峰》

RFC6749 

1.2.  Protocol Flow

     +--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

4.1 Authorization Code Grant

     +----------+
     | Resource |
     |   Owner  |
     |          |
     +----------+
          ^
          |
         (B)
     +----|-----+          Client Identifier      +---------------+
     |         -+----(A)-- & Redirection URI ---->|               |
     |  User-   |                                 | Authorization |
     |  Agent  -+----(B)-- User authenticates --->|     Server    |
     |          |                                 |               |
     |         -+----(C)-- Authorization Code ---<|               |
     +-|----|---+                                 +---------------+
       |    |                                         ^      v
      (A)  (C)                                        |      |
       |    |                                         |      |
       ^    v                                         |      |
     +---------+                                      |      |
     |         |>---(D)-- Authorization Code ---------'      |
     |  Client |          & Redirection URI                  |
     |         |                                             |
     |         |<---(E)----- Access Token -------------------'
     +---------+       (w/ Optional Refresh Token)

通常来说我们会把 认证服务 与 资源服务 整合到一起，若我们把上述过程用时序图绘制出来，效果如下：

通过OAuth2协议通常来说是虚拟用户先访问目标应用系统的登录页，通过登录页的链接跳转到认证服务器上进行认证授权操作，应用系统在对接系统时只需要提供一个标准的回调接口就可以实现OAuth的对接。

但是这种方式存在一个问题：用户在每访问以个应用都需需要执行OAuth2一整套流程，访问多个系统也就需要在OAuth2认证服务上认证多次。

为了实现单点登录的 登录一次访问所有的设计思想，我们需要对OAuth2部分流程作出一定调整，需求如下：

1. 用户不再需要只需要登录单点登录服务，不需要单独进入其他应用。
2. 用户登录后通过单点登录服务页面的连接访问应用，登录期间不需要再次认证。
3. 应用系统对接单点登录系统只需要按照标准的OAuth2协议对接。

调整后整合了OAuth2的单点登录时序如下：

1. 用户登录SSO系统而不是应用系统。
2. 认证后进入系统列表显示已经对接的应用
3. 在用户点击应用后，SSO系统根据应用注册提供的回调地址，按照OAuth2协议返回带有授权码的重定向请求。
4. 浏览器重定向至应用系统的OAuth2标准接口，剩下的流程与OAuth2协议保持一致。

该方案只需要设计好SSO系统的认证、用户会话管理、应用跳转时的301重定向流程，其它与OAuth2保持一致。

过去已经按照OAuth2对接的应用，在这样流程下无序任何调整，新对接的应用系统按照OAuth2协议提供标准的回调接口就可以实现OAuth的对接，由较高的兼容性。

参考文献

[1]. 理解OAuth 2.0 . 阮一峰 . 2014.05 . https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
[2]. ietf . RFC6749 The OAuth 2.0 Authorization Framework . 2012.10 . https://datatracker.ietf.org/doc/html/rfc6749#section-4.1