Spring Cloud Security 之 OAuth2.0

 

参考文章：http://www.cnblogs.com/Irving/p/9343377.html

 

1、 OAuth2.0 基础

　　概念：OAuth2.0 一个受权框架，它容许用户让第三方应用访问该用户在某服务的特定私有资源，可是不提供帐号密码消息给第三方应用

　　角色： 

• • resource owner（资源全部者）
  • resource server（资源服务器）
  • client（客户端）：表明资源全部者而且通过全部者受权去访问受保护的资源的应用程序
  • authorization server（受权服务器）：在成功验证资源全部者并得到受权后向客户端发出访问令牌

　　受权模式：

　　Authorization code（受权码模式）

　　标准的 Server 受权模式，很是适合 Server 端的 Web 应用。一旦资源的拥有者受权访问他们的数据以后，他们将会被重定向到 Web 应用并在 URL 的查询参数中附带一个受权码（code）。在客户端里，该 code 用于请求访问令牌（access_token）。而且该令牌交换的过程是两个服务端以前完成的，防止其余人甚至是资源拥有者本人获得该令牌。另外，在该受权模式下能够经过 refresh_token 来刷新令牌以延长访问受权时间，也是最为复杂的一种方式。

　　Implicit Grant（隐式模式）

　　该模式是全部受权模式中最简单的一种，并为运行于浏览器中的脚本应用作了优化。当用户访问该应用时，服务端会当即生成一个新的访问令牌（access_token）并经过URL的#hash段传回客户端。这时，客户端就能够利用JavaScript等将其取出而后请求API接口。该模式不须要受权码（code），固然也不会提供refresh token以得到长期访问的入口。

　　Resource Owner Password Credentials（密码模式）

　　本身有一套用户体系，这种模式要求用户提供用户名和密码来交换访问令牌（access_token）。该模式仅用于很是值得信任的用户，例如API提供者本人所写的移动应用。虽然用户也要求提供密码，但并不须要存储在设备上。由于初始验证以后，只需将 OAuth 的令牌记录下来便可。若是用户但愿取消受权，由于其真实密码并无被记录，所以无需修改密码就能够当即取消受权。token自己也只是获得有限的受权，所以相比最传统的 username/password 受权，该模式依然更为安全。

　　Client Credentials（客户端模式）

　　没有用户的概念，一种基于 APP 的密钥直接进行受权，所以 APP 的权限很是大。它适合像数据库或存储服务器这种对 API 的访问需求。

 

2、OAuth2.0受权流程

　　

1. (A)  客户端向资源全部者请求其受权
2. (B)  客户端收到资源全部者的受权许可，这个受权许但是一个表明资源全部者受权的凭据
3. (C)  客户端向受权服务器请求访问令牌，并出示受权许可
4. (D)  受权服务器对客户端身份进行认证，并校验受权许可，若是都是有效的，则发放访问令牌
5. (E)  客户端向资源服务器请求受保护的资源，并出示访问令牌
6. (F)  资源服务器校验访问令牌，若是令牌有效，则提供服务

3、Refresh Token流程

　　

　　刷新的流程如图所示：

1. (A)  客户端请求获取访问令牌，并向受权服务器提供受权许可
2. (B)  受权服务器对客户端身份进行认证，并校验受权许可，若是校验经过，则发放访问令牌和刷新令牌
3. (C)  客户端访问受保护的资源，并向资源服务器提供访问令牌
4. (D)  资源服务器校验访问令牌，若是校验经过，则提供服务
5. (E)  重复(C)和(D)直到访问令牌过时。若是客户端直到访问令牌已通过期，则跳至(G)，不然不能继续访问受保护的资源
6. (F)  自从访问令牌失效之后，资源服务器返回一个无效的令牌错误
7. (G)  客户端请求获取一个新的访问令牌，并提供刷新令牌
8. (H)  受权服务器对客户端进行身份认证并校验刷新令牌，若是校验经过，则发放新的访问令牌（而且，可选的发放新的刷新令牌）