Gateway + Oauth2 + Security认证与授权
讲道理，Security是目前知道的框架中最难掌握的一个框架，我接下来的学习目标都将围绕它而展开，
1.用户认证
1.1 : 用户认证与授权
用户认证
-
当用户去访问我们的系统资源的时候，我们的系统需要验证用户的身份（比如账号和密码认证这是一种方式），如果身份合法则认证通过，颁发相应的免死金牌，如果验证没通过，则提示用户请三思而后行，这就是用户认证
用户授权
-
用户授权一般是与用户认证相辅相成的，在认证的时候，如果认证通过，我们还会将该用户的权限信息给收集起来，并将相应信息作为依据，封装在认证的响应体中（JWT），当用户认证成功后，访问我们系统的某一个模块的时候，该模块是需要判断该用户是否有权访问，如果没有访问该资源的访问权限，用户也只有被拒绝访问，这就是用户授权
1.2 : 单点登陆问题 SSO
单点登陆
-
单点登陆一般常见于分布式项目中，用户只需要登陆一次，即认证一次，即可访问分布式项目中的所有模块，而不需要每访问一个模块就得去登陆认证一次，这样用户嫌麻烦，后端认证逻辑也冗余
1.3 : 第三方登陆
比如目前互联网运用中的微信登陆、微博登陆、支付宝登陆等
-
用户通过授权，第三方应用给予我们系统访问他微信相关信息的权限，我们获取后进行注册，使其称为我们系统的注册人员，实现第三方登陆
2.关于Oauth2认证
2.1 : 认识Oauth2
Oauth2我认为是一种认证与授权的思想，我们可以将其运用在项目中，成为我们项目认证和授权的解决方案
首先Oauth2中有以下几个角色： <我们就以微信登陆为列>
客户端
-
就假如是我们自己的系统吧，这个客户端和Oauth2不沾亲带故，可以是任何独立的系统，比如我们的某个系统，或者某个app客户端又或者是我们的系统web客户端
资源拥有者
-
就是指我们的用户，比如微信登录中，在面对微信的数据库时，我们的系统就是无关人员，而登陆的用户，在微信的系统中就是该用户信息的资源拥有者，他掌握着是否将他的微信个人信息暴露给我们的系统
授权服务器
-
在微信登陆中，就是用来辨别用户的认证是否正确，是否可以成为该微信用户信息的资源拥有者，在微信登陆中，该系统由微信系统提供，用于鉴别资源拥有者的身份合法性
资源服务器
-
这个就很简单了，守护该微信用户信息的服务器，他掌握着微信的用户信息，我们的客户端最后就是向他发起请求，想面对甲方一样，求着他给我们响应该用户的微信个人信息。
2.2 : Oauth2实现之三方登陆流程
接着上面的我们继续加固我们对Oauth2的认识，下面我们就以微信登陆为列子，来说说Oauth2的运用实现，已经一般在项目中，Oauth2这种思想可以帮我们解决哪些问题
-
首先用户，登陆我们的客户端，点击微信登陆
-
系统请求微信的授权系统，响应一个二维码给用户，用户扫码后点击同意
-
微信的授权服务器会对该微信用户进行验证
-
验证通过后，返回一个询问页面，是否授权给某某系统
-
用户点击确认，认证服务就会颁发一个授权码给客户端，并重定向我们的系统
-
-
此时我们的客户端获得授权码，根据授权码去微信的认证服务申请令牌
-
微信的认证服务器认证通过后，会颁发一个令牌给我们的系统
-
当系统拿到令牌时，也就是微信登陆成功之时
-
该令牌代表着我们的系统，有权访问该微信用户在微信中的个人信息数据
-
-
我们的客户端携带令牌去微信的资源服务器获取该微信用户的个人信息
-
微信资源服务器校验该令牌的合法性，通过后响应该用户的微信个人信息数据给我们的客户端
整体流程如下所示
2.3 : Oauth2的运用
思想在上面已经说明的还算通透了，总结以下，受保护的资源需要某种标识，这个标识可以用户自己携带而来的（自己系统），也可以是外来系统在用户授权后带来的（外来系统），只要该标识验证通过，则资源访问放行，对外暴露请求接口，所以Oauth2的主要运用就是
-
保护某个资源只有在通过授权的情况下，才运行被请求
-
第三方登陆流程是一个列子
-
我们假如做大做强，我们的系统服务也可以通过上面的方式暴露给外来系统某些受保护的数据
-
本系统前端访问后端资源，也可以解决一个授权问题
-
再其次就是我们系统服务之间的相互调用，当然这个做的就有点严谨了，但是思想是这个思想
-
Spring Security + Oauth2：认证授权方案
-
用户携带账号密码 (或者三方登陆 )请求认证服务等，请求用户认证
-
认证通过后，颁发身份令牌可客户端，并将身份令牌储存在Redis中
-
用户携带身份令牌请求资源服务，必经网关
-
网关获取客户端带来的令牌和Redis中的令牌进行比对校验
-
校验通过，服务转发，资源服务器获取到令牌，根据令牌完成授权
-
资源服务通过授权后响应数据给客户端
.