关于 SpringCloud oauth2 JWT 认证与授权解决用户信息变更token失效问题的解决（伪）

oauth2不是什么简单的东西，本文不适用于从零搭建oauth2环境。

网上会告诉你的解决方式

将token存入redis，每次访问验证redis里的token对应的用户信息。判断是否密码变更，账号是否过期等信息。

这是我在网上能找到的的关于jwt的教程中看到最为广泛的一种做法，个人非常抗拒这种做法。

回顾一下授权与认证方式的演变过程，从我接触Java开始。

我们使用最原始的就是session模式，有状态模式，利用客户端与服务端的session缓存来达到辨别用户的目的。时至今日，我们仍然可以看到一些项目在使用。

之后是redis时代，有状态模式（为了解决分布式session共享应景而生的一种手段），利用redis存放session来达到不同实例之间的session共享。

最后是令牌模式，无状态模式（中间经历了多少其实我并不清楚，因为我其实除了学习阶段，上手便是JWT），也就是token模式，token模式的出现又为了解决什么样的问题呢。答案是服务器压力，用户量日益增加的web服务如果每建立一个会话就在服务端存放一条session缓存，无疑对服务器的压力是巨大的。而且session也不并不安全，当然这不是本文讨论的内容。

JWT无法解决的痛点，即，token颁发后则脱离控制，无法使之失效的问题。

再来说说开篇为什么说个人抗拒使用redis来存放token的做法。其实已经显而易见了。之所以使用jwt，就是因为要解决服务器存放session带来的巨大服务器压力。这倒好，好不容易从有状态进化到无状态模式，一个redis，又给整回去了！

记住一件事情，使用Token模式（严谨的讲，是基于JWT的Token模式，实际上springcloud oauth2 原生token就是个session_id，仅此而已），首先第一点，禁用任何形式的session，否则，请用回session模式

来说说我的想法

题外话：单点登录也不要使用Nginx来把服务都转发到统一域名下，然后共享Cookies来实现。可不可行？可行，但是非常的low。因为如果把Nginx看成一个整体的服务。那么这种做法无疑是单点了个寂寞（下次有时间再深入讨论这个问题）。

我们都知道，oauth2认证模式，授权码模式，隐藏模式，密码模式，客户端模式，此外还有一种，刷新令牌模式，这并非单独的一种，而是以上4中都可以配合刷新token模式来使用。

而我们这里讲最严谨的授权码模式，采用自动授权方式（即：登陆后不用手动点击授权）。

思路：

已知：刷新令牌（refresh token）的作用，在token过期后，可以在不登陆的情况下使用刷新token到认证服务器获取新的token而无需再次登录。

得知：以短到令人发指的token失效时间来保证已颁发的令牌总是失效（5分钟，甚至更短）。在token失效时使用隐蔽的方式重新获得新的token，就可以达到一种修改密码之后，原来的token会在5分钟甚至更短时间之内失效。而如果没有密码变更，则一直可以访问。但是token5分钟变化一次用户却感知不到的一种效果。用户无感知，密码改了，token失效了。不就是我们想达到的效果吗。尽管它并不是实时的，但是至少看上去是像的。

理论可行，实践开始

认证与授权服务器关键代码（本文非小白文，如果从搭建开始讲起，那得写本书）

客户端的配置

// 客户端配置
@Override
public void configure(ClientDetai