SpringCloud + oauht2.0 实现微服务的认证和授权（一）

1. 微服务为什么要使用oauth2

1.1 跨服务之间的通讯问题

看上图，我们以前的架构图是这样的，当用户请求过来，我们把用户的信息存储到了tomcat的session中，然后每个模块我们通过session去获得用户的信息，如果我们的tomcat多了呢？

每个tomcat就是一个线程 那么我们如何从 另一个tomcat 拿到上一个的session呢，显然这样是做不到的

1.2 解决办法：

实现tomcat的session共享：当前这种方法以前做的比较多 ，但是当前不推荐使用，给服务器的压力会变大
用户信息存储到前端 ：当用户访问后，颁发给用户一个token，用户的信息就存储到这个token里面，引出了OAuth

2. oauth2.0的四种模式：

• 授权码（authorization-code）：指的是第三方应用先申请一个授权码，然后再用该码获取令牌
• 密码式（password）：指的是通过帐号密码来获取令牌
• 客户端凭证（client credentials）：适用于没有前端的命令行应用，即在命令行下请求令牌。
• 隐藏式（implicit）：有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）。

2.1:密码模式（适用于app）：

下面的demo主要用的是 密码模式

2. oauth2.0的认证流程：

从上图我们来看，用户通过客户端访问我们的资源，先让用户去认证，颁发完令牌，然后去订单服务去判断当前令牌的真实性，如果我们资源服务越来越多，那岂不是每个都要配置？这样使我们的资源服务器变的很繁琐！ 配置微服务网关，我们只需要在网关去拦截令牌并且验证令牌

密码模式配置前往

3. 微服务网关 ：

这里我们引进来了网关，每个请求来了 我们去获取令牌，在网关去判断当前令牌的真实性，资源服务，就不再去做登录的逻辑了，这样就算我们的资源服务器再多 ，我们只需要配置网关，让登陆的逻辑在网关中去判断就可以了

网关配置前往