Spring Cloud(6)：保护微服务（Security） - OAuth2.0

OAuth2是一个授权（Authorization）协议。我们要和Spring Security的认证（Authentication）区别开来，认证（Authentication）证明的你是不是这个人，而授权（Authorization）则是证明这个人有没有访问这个资源（Resource）的权限。
下面这张图来源于OAuth 2.0 authorization framework RFC Document，是OAuth2的一个抽象流程。

     +--------+                               +---------------+
     |        |--(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 ---|               |
     +--------+                               +---------------+

先来解释一下上图的名词：

  Resource Owner：资源所有者，即用户

  Client：客户端应用程序（Application）

  Authorization Server：授权服务器

  Resource Server：资源服务器

再来解释一下上图的大致流程：

（A） 用户连接客户端应用程序以后，客户端应用程序要求用户给予授权

（B） 用户同意给予客户端应用程序授权

（C） 客户端应用程序使用上一步获得的授权（Grant），向授权服务器申请令牌

（D） 授权服务器对客户端应用程序的授权（Grant）进行验证后，确认无误，发放令牌

（E） 客户端应用程序使用令牌，向资源服务器申请获取资源

（F） 资源服务器确认令牌无误，同意向客户端应用程序开放资源

从上面的流程可以看出，如何获取授权（Grant）才是关键。在OAuth2中有4种授权类型：

1. Authorization Code（授权码模式）：功能最完整、流程最严密的授权模式。通过第三方应用程序服务器与认证服务器进行互动。广泛用于各种第三方认证。

2. Implicit（简化模式）：不通过第三方应用程序服务器，直接在浏览器中向认证服务器申请令牌，更加适用于移动端的App及没有服务器端的第三方单页面应用。

3. Resource Owner Password（密码模式）：用户向客户端服务器提供自己的用户名和密码，用户对客户端高度信任的情况下使用，比如公司、组织的内部系统，SSO。

4. Client Credentials（客户端模式）：客户端服务器以自己的名义，而不是以用户的名义，向认证服务器进行认证。

下面主要讲最常用的（1）和（3）。此外，还有一个模式叫Refresh Token，也会在下面介绍。

Authorization Code（授权码模式）

     +----------+
     | 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)
 
   Note: The lines illustrating steps (A), (B), and (C) are broken into
   two parts as they pass through the user-agent.

它的步骤如下：

（A） 用户（Resource Owner）通过用户代理（User-Agent）访问客户端（Client），客户端索要授权，并将用户导向认证服务器（Authorization Server）。

（B） 用户选择是否给予客户端授权。

（C） 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码。

（D） 客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E） 认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）。这一步也对用户不可见。

Resource Owner Password（密码模式）

     +----------+
     | Resource |
     |  Owner   |
     |          |
     +----------+
          v
          |    Resource Owner
         (A) Password Credentials
          |
          v
     +---------+                                  +---------------+
     |         |>--(B)---- Resource Owner ------->|               |
     |         |         Password Credentials     | Authorization |
     | Client  |                                  |     Server    |
     |         |<--(C)---- Access Token ---------<|               |
     |         |    (w/ Optional Refresh Token)   |               |
     +---------+                                  +---------------+
 
            Figure 5: Resource Owner Password Credentials Flow

它的步骤如下：

（A） 用户（Resource Owner）向客户端（Client）提供用户名和密码。

（B） 客户端将用户名和密码发给认证服务器（Authorization Server），向后者请求令牌。

（C） 认证服务器确认无误后，向客户端提供访问令牌。

令牌刷新（refresh token）

  +--------+                                           +---------------+
  |        |--(A)------- Authorization Grant --------->|               |
  |        |                                           |               |
  |        |<-(B)----------- Access Token -------------|               |
  |        |               & Refresh Token             |               |
  |        |                                           |               |
  |        |                            +----------+   |               |
  |        |--(C)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(D)- Protected Resource --| Resource |   | Authorization |
  | Client |                            |  Server  |   |     Server    |
  |        |--(E)---- Access Token ---->|          |   |               |
  |        |                            |          |   |               |
  |        |<-(F)- Invalid Token Error -|          |   |               |
  |        |                            +----------+   |               |
  |        |                                           |               |
  |        |--(G)----------- Refresh Token ----------->|               |
  |        |                                           |               |
  |        |<-(H)----------- Access Token -------------|               |
  +--------+           & Optional Refresh Token        +---------------+

具体流程不再分析，我们已知，当我们申请token后，Authorization Server不仅给了我们Access Token，还有Refresh Token。当Access Token过期后，我们用Refresh Token访问/refresh端点就可以拿到新的Access Token了。

本节只讲概念，在接下来的几节中会搭建一组含有Client Application, Authorization Server, Resource Server的微服务群，并使用Eureka和Config组件管理。