Spring Cloud Security
Spring Cloud Security
Spring Cloud Security用于构建微服务的安全应用程序和服务，它可以轻松实现微服务系统架构下的统一安全认证与授权。
Spring Cloud Security 有以下组件。
- spring-cloud-security：为Zuul、Feign、Oauth 2.0 的Resource Server 的Token中继提供支持。
- spring-cloud-starter-security：管理在Spring Cloud中使用Spring Security的依赖。
- spring-cloud-starter-oauth：管理在Spring Cloud 中使用Spring Security Oauth2的依赖。
1. OAuth 2.0 概述
OAuth 2.0是一个标准的授权协议。实际上它是用户资源和第三方应用之间的一个中间层，把资源和第三方应用隔开，使得第三方应用无法直接访问资源，第三方应用要访问资源需要通过提供凭证获得OAuth 2.0授权，从而起到保护资源的作用。
如果智艺安拥有者允许第三方访问资源，则可以将用户名和密码告诉第三方应用，让第三方应用直接以资源所有者的身份进行访问。还可以不提供用户名和密码，而通过授权的方式让第三方应用进行访问。
比如，微信公众号授权提醒就还是OAuth2.0 的一个应用场景。页面弹出一个提示框提示需要获取我们的个人信息。如果我们单击“确认”按钮，则授权第三方应用获取我们在微信公众平台中的个人信息。
1.1 OAuth 2.0 的角色
在OAuth 2.0 的认证授权过程中，主要涉及以下4种角色。
（1）授权的服务提供方（Authorization Server）。它是安全服务器，进行访问的认证和授权。
（2）资源所有者（Resource Owner）。一般情况下，用户就是资源的所有者，比如用户的头像、照片、名称和手机号等私有数据。
（3）资源服务器（Resource Server）。存在用户资源的服务器。
（4）客户端（Client）。它可以是任何第三方应用，与授权和资源服务提供方无关。在用户授权第三方获取用户私有资源后，第三方通过获取到Token等信息通过授权服务器认证，然后去资源服务器获得资源。
1.2 OAuth 2.0 的运行流程
- 用户打开客户端，客户端要求用户给予授权。
- 用户同意给客户端授权。
- 客户端使用上一步获得的授权向安全服务器申请令牌。
- 安全服务器对客户端进行认证，在确认无误后发放令牌。
- 客户端使用令牌向资源服务器申请获取资源。
- 资源服务器确认令牌无误，向客户端开放资源。
2.客户端的授权模式
客户端必须得到用户的授权（Authorization Grant）才能获得令牌（Access Token）。OAuth 2.0 定义了4中授权方式。
- 密码模式（Resource Owner Password Credentials Grant）。
- 客户端模式（Client Credentials Grent）。
- 简化模式（Implicit Grant）。
- 授权码模式（Authorization Code Grant）。
2.1 密码模式
在密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息向“服务商提供商”申请授权。如下图。
在这种模式中，用户必须把自己的密码给客户端，这就存在安全隐患，不能保证客户端不存储用户密码。所以这种模式通常用在用户对客户端高度信任的情况下，比如客户端是操作系统或者由一个著名公司出品。一般只有在其他授权模式无法执行的情况下，才考虑使用这种模式。
具体运行过程如下：
（1）用户向客户端提供用户名和密码。
（2）客户端将用户名和密码发给安全服务器，向其请求令牌。
客户端发出的HTTP请求中包含一下参数。
- grant_type：授权类型，此处的值固定为“password”，必选项。
- username：用户名，必选项。
- password：用户的密码，必选项。
- scope：权限范围，可选项。
（3）安全服务器确认无误后向客户端提供访问令牌。
2.2 客户端模式
客户端模式指，客户端以自己的名义向“安全服务器”进行认证。这种模式不存在授权问题。运行过程如下图。
（1）客户端向安全服务器进行身份认证，并申请一个访问令牌。
客户端发出的HTTP请求中包含以下参数。
- grant_type：授权类型，此处的值固定为“clientcredentials”，必选项。
- scope：权限范围，可选项。
（2）安全服务器确认无误后向客户端提供访问令牌。
3.简化模式
简化模式指，客户端不通过第三方应用程序的服务器，直接在浏览器中向安全服务器申请令牌。所有步骤都在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。运行过程如下图。
（1）客户端通过浏览器将用户导向安全服务器。
客户端发出的HTTP请求包含以下参数。
- response_type：授权类型，此处的值固定为“ token”，必选项。
- client_id：客户端的ID，必选项。
- redirect_uri：重定向的URI，可选项。
- scope：权限范围，可选项。
- state：客户端的当前状态，可以指定任意值，安全服务器会原封不动地返回这个值。注意，这个参数必须填写，否则会存在CSRF漏洞。安全服务器在将用户代理重定向时会带上该参数。
（2）用户决定是否授权客户端。
（3）如果用户给予授权，则安全服务器将用户导向客户端指定的“重定向URI”，并在该URI的Hash参数值部分包含访问令牌。
安全服务器回应客户端的URI中包含以下参数。
- access_token：访问令牌，必选项。
- token_type：令牌类型，该值大小写不敏感，必选项。
- expires_in：过期时间，单位为秒。如果省略该参数，则必须使用其他方式设置过期时间。
- scope：权限范围，如果与客户端申请的范围一致，则此项可省略。
- state：如果在客户端的请求中包含这个参数，则在安全服务器的回应中也必须一模一样包含这个参数。
（4）客户端通过浏览器向资源服务器发出请求，其中不包括上一步收到的Hash 值。
（5）资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌。
（6）浏览器执行上一步获得的脚本，提取出令牌。
（7）浏览器将令牌传送给客户端。
4.授权码模式
在授权码模式中，客户端是通过其后台服务器与安全服务器进行交互的。运行过程如下图。
（1）用户访问客户端。
（2）客户端将用户导向安全服务器。
客户端申请宁认证的URI中包含以下参数。
- response_type：授权类型，必选项，此处的值固定为“code”。
- client_id：客户端的ID，必选项。
- redirect_uri：重定向URI，可选项。
- scope：申请的权限范围，可选项。
- state：客户端的当前状态，可以指定任意值，安全服务器会原封不动地返回这个值。这个参数应该填写，建议state参数用动态数据，否则会存在CSRF漏洞。
（3）用户选择是否给客户端授权。
（4）如果用户同意授权，则安全服务器会将用户导向到客户端事先指定的“重定向URI”，并附上一个授权码。
服务器回应客户端的URI中包含以下参数。
- code：授权码，必选项。该码的有效期应该很短，通常为几分钟。客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端的ID和重定向URI是对应关系。
- state：如果在客户端的请求中包含这个参数，则安全服务器的回应也必须一模一样包含这个参数。
（5）客户端收到授权码，附上“重定向URI”，向安全服务器申请令牌。
客户端向安全服务器申请令牌的HTTP请求包含一下参数。
- grant_type：使用的授权模式，必选项。授权码模式的值为“authorization_code”。
- code：上一步获得的授权码，必选项。
- redirect_uri：重定向URI，必选项，且必须与步骤（2）中的该参数值保持一致。
- client_id：客户端ID，必选项。
（6）安全服务器核对授权码和重定向URI，确认无误后向客户端发送访问令牌（access_token）和更新令牌（refresh_token）。
安全服务器发送的HTTP回复中包含以下参数。
- access_token：访问令牌，必选项。
- token_type：令牌类型，该值大小写不敏感，必选项，可以是Bearer等类型。
- expires_in：过期时间，单位为秒。
- refresh_token：更新令牌，可选项。
- scope：权限范围。如果其范围与客户端申请的范围一致，则此项可省略。
如果在用户访问时客户端的“访问令牌”已经过期，则用户需要用更新令牌申请一个新的访问令牌。
客户端发出更新令牌的HTTP请求包含以下参数。
- grant_type：使用的授权模式，必选项。
- refresh_token：刷新令牌。通过以上授权获得的刷新令牌来获取新的令牌，必选项。
- scope：申请的授权范围，不可以超出上一次申请的范围。如果省略该参数，则表示与上一次一致。