Spring Cloud(6)：保护微服务（Security）
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组件管理。