传统的服务端有状态Session至JWT的无状态至OAuth2至OAuth2+JWT

采用令牌的方式可以让用户灵活地对第三方应用授权或者收回权限，OAuth2是OAuth协议的下一个版本，但不向下兼容OAuth 1.0。OAuth2关注客户端开发者的简易性，同时为Web应用、桌面应用、移动设备、起居室设备提供专门的认证流程，传统的Web开发登录认证一般都是基于Session的，但是前后端分离的架构中继续使用Session会有很多不便，因为移动端要么不支持cookie（微信小程序），要么使用非常不便，对于这些问题，使用OAuth2认证都能解决。

OAuth2授权有4种模式，我们自己做前后端分离登录就可以采用密码模式。微服务中有一个特殊的场景，就是服务之间的调用，用密码模式做鉴权是非常恰当不过的了

0.OAuth2中的角色都有哪些？

0.1 资源拥有者
可以是一个人也可以是一个公司实体，对资源持有的实体。

0.2 资源服务
受保护的资源，可以使用token令牌来访问

0.3 客户端
需要请求资源的应用客户端，PC，APP

0.4 认证服务
发放令牌的服务，验证资源所有者并获得授权

1.为什么要用无状态服务的代替有状态服务的？

有状态服务，即服务端需要记录每次会话的客户端信息，从而识别客户端身份，根据用户身份进行请求的处理，典型的设计如 Tomcat 中的 Session。例如登录：用户登录后，我们把用户的信息保存在服务端 session 中，并且给用户一个 cookie 值，记录对应的 session，然后下次请求，用户携带 cookie 值来（这一步有浏览器自动完成），我们就能识别到对应 session，从而找到用户的信息。这种方式目前来看最方便，但是也有一些缺陷，如下：

服务端保存大量数据，增加服务端压力
服务端保存用户状态，不支持集群化部

2.无状态性有哪些好处呢？

客户端请求不依赖服务端的信息，多次请求不需要必须访问到同一台服务器
服务端的集群和状态对客户端透明
服务端可以任意的迁移和伸缩（可以方便的进行集群化部署）
减小服务端存储压力

3.如何实现无状态？无状态的登陆流程:

首先客户端发送账户名/密码到服务端进行认证
认证通过后，服务端将用户信息加密并且编码成一个 token，返回给客户端
以后客户端每次发送请求，都需要携带认证的 token
服务端对客户端发送来的 token 进行解密，判断是否有效，并且获取用户登录信息

4.JWT存在的问题：

续签问题，这是被很多人诟病的问题之一，传统的 cookie+session 的方案天然的支持续签，但是 jwt 由于服务端不保存用户状态，因此很难完美解决续签问题，如果引入 redis，虽然可以解决问题，但是 jwt 也变得不伦不类了。
注销问题，由于服务端不再保存用户信息，所以一般可以通过修改 secret 来实现注销，服务端 secret 修改后，已经颁发的未过期的 token 就会认证失败，进而实现注销，不过毕竟没有传统的注销方便。
密码重置，密码重置后，原本的 token 依然可以访问系统，这时候也需要强制修改 secret。
基于第 2 点和第 3 点，一般建议不同用户取不同 secret

5.单纯的使用OAuth2的password模式有问题吗？

我们知道授权服务器派发了 access_token 之后，客户端拿着 access_token 去请求资源服务器，资源服务器要去校验 access_token 的真伪，所以我们在资源服务器上配置了 RemoteTokenServices，让资源服务器做远程校验

@Bean
RemoteTokenServices tokenServices() {
    RemoteTokenServices services = new RemoteTokenServices();
    services.setCheckTokenEndpointUrl("http://localhost:8080/oauth/check_token");
    services.setClientId("javaboy");
    services.setClientSecret("123");
    return services;
}

在高并发环境下这样的校验方式显然是有问题的，如果结合 JWT，用户的所有信息都保存在 JWT 中，这样就可以有效的解决上面的问题。

6. OAuth2中存储令牌的方式:

我们可以把令牌存储在内存中，但是如果部署多个服务，就会导致无法使用令牌的问题。 Spring Cloud Security中有两种存储令牌的方式可用于解决该问题，一种是使用Redis来存储，另一种是使用JWT来存储