Spring Cloud Gateway + Jwt + Oauth2 实现网关的鉴权 *** 作

前面讲述了一下 spring security对认证的实现 ，该实现的使用场景主要是用户本人认证。
有一种场景是用户将授权给第三方应用，访问本人在该应用的资源。
站在应用的角度出发，就是经得用户授权以后，对第三方应用认证，获取访问用户资源的权限。

oauth2就是一种用户对第三方应用授权，获取用户在本应用资源访问权限的协议标准。
该协议中针对第三方应用有四种认证方式。

相关认证的类型选择流程如下所示：

关于Spring对oauth2的实现框架图如下所示：

其中：

所以认证的主要逻辑都在认证授权服务上（AuthorizationServer）。
其中：

其中对不同的oauth2协议的认证协议实现，主要是通过 TokenGranter 接口的 grant 方法的实现。
TokenGranter接口及相关的实现类的关系图所下所示：

在介绍Spring Cloud Security之前，我们先要介绍一下Spring Security。

Spring Security是一套提供了完整的声明式安全访问控制的解决方案。
Spring Security是基于Spring AOP和Servlet过滤器的，它只能服务基于Spring的应用程序。
除常规认证和授权外，它还提供 ACL，LDAP，JAAS，CAS 等高级安全特性以满足复杂环境中的安全需求。

(注:在Spring Security中，Authority和Permission是两个完全独立的概念，两者没有必然的联系。它们之前需要通过配置进行关联。)

安全方案的实现通常分为 认证(Authentication) 和 授权(Authorization) 两部分。

使用者可以使一个 用户 ， 设备 ，和可以在应用程序中执行某种 *** 作的 其它系统 。

认证一般通过用户名和密码的正确性校验来完成通过或拒绝。

Spring Security支持的主流认证如下:

Spring Security进行认证的步骤:
++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ 1 用户使用用户名和密码登陆
++
++ 2 过滤器(UsernamePasswordAuthenticationFilter)获取到用户名
++    和密码，将它们封装成Authentication
++
++ 3 AuthenticationManager认证Token(由Authentication实现类传递)
++
++ 4 AuthenticationManager认证成功，返回一个封装了用户权限信息
++    的Authentication对象，包含用户的上下文信息(角色列表)
++
++ 5 将Authentication对象赋值给当前的SecurityContext，建立这个用户
++ 的安全上下文( SecurityContextHoldergetContextsetAuthentication() )
++
++ 6 当用户进行一些受到访问控制机制保护的 *** 作，访问控制机制会依据
++    当前安全的上下文信息来检查这个 *** 作所需的权限
++++++++++++++++++++++++++++++++++++++++++++++++++++++

Spring Security提供了一系列基本组件，如spring-security-acl, spring-security-cas, spring-security-oauth2等。
具体这里就不详述了，读者可以查看官网的介绍。

 

Spring Cloud Security是用于构建微服务系统架构下的安全的应用程序和服务，它可以轻松实现基于微服务架构的统一的安全认证与授权。

Spring Cloud Security相对于Spring Security整合了Zuul，Feign，而且更加完美地整合了OAuth20。

 

OAuth 20是用于授权的行业标准协议。

原理:
OAuth2是用户资源和第三方应用之间的一个中间层。
它把资源和第三方应用隔开，使得第三方应用无法直接访问资源，第三方应用要访问资源需要通过提供 凭证(Token) 来获得OAuth 20授权。

OAuth2的典型例子:

==============================================
== 微信公众号授权提醒
== 页面d出一个提示框需要获取我们的个人信息
== 单击确定
== 第三方应用会获取我们在微信公众平台中的个人信息
==============================================

OAuth的关键角色:

在用户授权第三方获取私有资源后，第三方通过获取到的token等信息通过授权服务器认证，然后去资源服务器获取资源。

 

密码模式中，资源拥有者负责向客户端提供用户名和密码；
客户端根据用户名和密码箱认证服务器申请令牌，正确后认证服务器发放令牌。

客户端请求参数:

缺点:
用户对客户端高度可信，必须把自己的密码发给客户端，存在被黑客窃取的隐患(不推荐)。

在授权码模式中，客户端是通过其后台服务器与认证服务器进行交互的。

授权码模式的运行流程:

从以上图中我们可以看到客户端服务器和认证服务器需经过2次握手，客户端服务器才能拿到最终的访问和更新令牌。

客户端申请认证的参数:

 

服务器返回的参数:

 

客户端收到授权码以后，附上重定向URI，向认证服务器申请访问令牌。

客户端申请令牌的参数:

 

服务器返回的参数:

 

如果访问令牌已经过期，可以使用更新令牌申请一个新的访问令牌。

通过更新令牌申请访问令牌的参数:

这两种模式不常用，因此在这里就不多叙述了。

---