有图解有案例，我终于把OAuth2.0搞清楚了

是一个关于授权（）的开放网络标准，用来授权第三方应用获取用户数据，是目前最流行的授权机制，它当前的版本是2.0。

之前，我们先来了解一下它里边用到的名词定义吧：

官网的认证流程图，我们来分析一下：

的服务，我们得先创建几张表。

相关的建表语句可以参考官方初始化sql，也可以查看阿Q项目中的init.sql文件，私信回复“oauth2”获取源码。

表中添加一条数据

和日志进行了配置。

并增加注解开启资源服务，重写两个方法

，在上边的中进行配置

的和实现了的放到项目中，当请求发过来时，会帮我们自行校验。

和日志进行了配置。

的的实现类重写方法

类，增加注解并重写方法

类，增加注解开启认证服务

对象

接口时会提示以下错误

请求，前边的路径是固定形式的，表示获取授权码，表示客户端的名称是我们数据库配置的数据。

的默认页面，输入用户的账户密码点击登录会提示我们进行授权，这是数据库表我们设置为起到的效果。

点击按钮，会发现我们设置的回调地址（表中的）后边拼接了值，该值就是授权码。

和表已经存入数据了。

之后和表中会存入数据以用于后边的认证。而表中的数据被清除了，这是因为值是直接暴漏在网页链接上的，为了防止他人拿到非法请求而特意设置为仅用一次。

去请求资源服务的接口，此时有两种请求方式

的其它模式。

。

跳转到登录页进行登录，表示获取。

，我们就可以像授权码方式一样携带去请求资源了。

直接暴漏在浏览器中，非常不安全，不建议使用。

的范畴了，用户直接在客户端进行注册，然后客户端去认证服务器获取令牌时不需要携带用户信息，完全脱离了用户，也就不存在授权问题了。

内置的动态配置

类增加注解

和两个模块设置了不同的包名，导致发送请求获取资源时报错。

表的中，在进行校验时会根据取出该字段进行反序列化，如果此时发现包名不一致便会导致解析失败，因此请求资源失败。

和的数据清除，重新开始测试就可以了。

时发现数据库中存在，故不刷新，但进行校验时却用带有权限标识的前去校验导致失败。

进行了基本的讲解，并且手把手带大家完成了项目的搭建。大家在对授权码模式、简化模式、密码模式、客户端模式进行测试的同时要将重点放到授权码模式上。

原文：https://mp.weixin.qq.com/s/BNA42Agb_RFFiXJ8mlfhqw

作者：阿Q说代码

如果感觉本文对你有帮助，点赞关注支持一下

无感知刷新Token

在前后端分离的应用中，使用Token进行认证是一种较为常见的方式。但是，由于Token的有效期限制，需要不断刷新Token，否则会导致用户认证失败。为了解决这个问题，可以实现无感知刷新Token的功能，本文将介绍如何实现无感知刷新Token。

在Web应用中，常见的Token认证方式有基于Cookie和基于Token的认证。基于Cookie的认证方式是将认证信息保存在Cookie中，每次请求时将Cookie发送给服务器进行认证；而基于Token的认证方式是将认证信息保存在Token中，每次请求时将Token发送给服务器进行认证。

在基于Token的认证方式中，客户端将认证信息保存在Token中，而不是保存在Cookie中。在认证成功后，服务器将生成一个Access Token和一个Refresh Token，并将它们返回给客户端。Access Token用于访问受保护的API，Refresh Token用于获取新的Access Token。

无感知刷新Token是指，在Token过期之前，系统自动使用Refresh Token获取新的Access Token，从而实现Token的无感知刷新，用户可以无缝继续使用应用。

在实现无感知刷新Token的过程中，需要考虑以下几个方面：

下面将介绍如何实现无感知刷新Token的具体步骤。

在认证成功后，需要将Access Token和Refresh Token发送给客户端。Access Token用于访问受保护的API，Refresh Token用于获取新的Access Token。可以使用JWT（jsON Web Token）或OAuth2（开放授权）等方式实现认证。

在JWT中，可以使用如下代码生成Access Token和Refresh Token：

在每个需要认证的API请求中，需要在请求头中携带Access Token，如下所示：

在前端中，可以使用AxIOS等库设置请求头：

在服务器返回401 Unauthorized响应时，说明Access Token已经过期，需要使用Refresh Token获取新的Access Token。可以使用Axios或Fetch API的中间件实现拦截。

在Axios中，可以使用如下代码实现：

在Fetch中，可以使用如下代码实现中间件：

在上述代码中，使用Axios或Fetch拦截401 Unauthorized响应，如果发现Access Token已经过期，则发送Refresh Token请求获取新的Access Token，并将新的Access Token设置到请求头中，重新发送请求。

在服务器端，需要编写API处理Refresh Token请求，生成新的Access Token，并返回给客户端。

在JWT中，可以使用如下代码生成新的Access Token：

在刷新Token时，需要验证Refresh Token的合法性，可以使用如下代码验证Refresh Token：

在上述代码中，使用JWT的verify方法验证Refresh Token的合法性，如果验证成功，则生成新的Access Token和Refresh Token，并返回给客户端。

为了避免Access Token过期时间太长，可以设置定时刷新Token的功能。可以使用定时器或Web Workers等方式实现定时刷新Token。在每次刷新Token时，需要重新获取新的Access Token和Refresh Token，并保存到客户端。

在上述代码中，使用定时器每14分钟刷新Token。在刷新Token成功后，将新的Access Token和Refresh Token保存到客户端，并将新的Access Token设置到请求头中。

在实现无感知刷新Token的过程中，需要考虑到Refresh Token的安全性问题。因为Refresh Token具有长期的有效期限，一旦Refresh Token被泄露，攻击者就可以使用Refresh Token获取新的Access Token，从而绕过认证机制，访问受保护的API。

为了增加Refresh Token的安全性，可以考虑以下几种措施：

JWT生成token及过期处理方案

在前后分离场景下，越来越多的项目使用token作为接口的安全机制，APP端或者WEB端（使用VUE、REACTJS等构建）使用token与后端接互，以达到安全的目的。本文结合stackover以及本身项目实践，试图总结出一个通用的，可落地的方案。

用户仅登录一次，用户改变密码，则废除token，重新登录

1.登录成功，返回access_token和refresh_token，客户端缓存此两种token;2.使用access_token请求接口资源，成功则调用成功；如果token超时，客户端携带refresh_token调用中间件接口获取新的access_token;3.中间件接受刷新token的请求后，检查refresh_token是否过期。如过期，拒绝刷新，客户端收到该状态后，跳转到登录页；如未过期，生成新的access_token和refresh_token并返回给客户端（如有可能，让旧的refresh_token失效），客户端携带新的access_token重新调用上面的资源接口。4.客户端退出登录或修改密码后，调用中间件注销旧的token(使access_token和refresh_token失效)，同时清空客户端的access_token和refresh_toke。

后端表id user_id client_id client_secret refresh_token expire_in create_date del_flag

场景： access_token访问资源 refresh_token授权访问 设置固定时间X必须重新登录

1.登录成功，后台jwt生成access_token（jwt有效期30分钟）和refresh_token（jwt有效期15天），并缓存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都能删除)，返回后，客户端缓存此两种token;2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）；客户端再次携带refresh_token调用中间件接口获取新的access_token;3.中间件接受刷新token的请求后，检查refresh_token是否过期。如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；如未过期，检查缓存中是否有refresh_token（是否被废除），如果有，则生成新的access_token并返回给客户端，客户端接着携带新的access_token重新调用上面的资源接口。4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token和refresh_token（废除）)，同时清空客户端侧的access_token和refresh_toke。5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：失效，长时间未登录，频繁刷新）

2.0 变动1.登录2.登录3.增加刷新access_token接口4.退出登录5.修改密码

场景：自动续期 长时间未使用需重新登录

1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token），设置access_token过期时间为7天，保证最终所有token都能删除)，返回后，客户端缓存此token;

2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的access_token，再次请求接口资源。

3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清空客户端侧的access_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）

5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。

3.0 变动

1.登录2.登录3.退出登录4.修改密码

1.3 场景：token过期重新登录 长时间未使用需重新登录

1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为 "user_id:access_token",value为access_token（根据用户id，可以人工废除指定用户全部token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此access_token；

2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的access_token，再次请求接口资源。

3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清空客户端侧的access_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长时间未登录，频繁刷新）

5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。

1.3 变动

1.登录2.登录3.退出登录4.修改密码

2.0 场景： access_token访问资源 refresh_token授权访问 设置固定时间X必须重新登录

1.登录成功，后台jwt生成access_token（jwt有效期30分钟）和refresh_token（jwt有效期15天），并缓

存到redis（hash-key为token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全

部token，也可以根据sub-key,废除部分设备的token。），设置过期时间为1个月，保证最终所有token都

能删除)，返回后，客户端缓存此两种token;

2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果

token超时，中间件删除access_token（废除）；客户端再次携带refresh_token调用中间件接口获取新的

access_token;

3.中间件接受刷新token的请求后，检查refresh_token是否过期。

如过期，拒绝刷新，删除refresh_token（废除）； 客户端收到该状态后，跳转到登录页；

如未过期，检查缓存中是否有refresh_token（是否被废除），如果有，则生成新的access_token并返回给

客户端，客户端接着携带新的access_token重新调用上面的资源接口。

4.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token和refresh_token（

废除）)，同时清空客户端侧的access_token和refresh_toke。

5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。

6.以上3刷新access_token可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（

拒绝的场景：失效，长时间未登录，频繁刷新）

2.0 变动

1.登录

2.登录

3.增加刷新access_token接口

4.退出登录

5.修改密码

3.0 场景：自动续期 长时间未使用需重新登录

1.登录成功，后台jwt生成access_token（jwt有效期30分钟），并缓存到redis（hash-key为

access_token,sub-key为手机号,value为设备唯一编号（根据手机号码，可以人工废除全部token，也可以

根据sub-key,废除部分设备的token。），设置access_token过期时间为1个月，保证最终所有token都能删

除)，返回后，客户端缓存此token;

2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果

token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的

access_token，

再次请求接口资源。

3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清

空客户端侧的access_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长

时间未登录，频繁刷新）

5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。

3.0 变动

1.登录

2.登录

3.退出登录

4.修改密码

4.0 场景：token过期重新登录 长时间未使用需重新登录

1.登录成功，后台jwt生成access_token（jwt有效期7天），并缓存到redis，key为

"user_id:access_token" + 用户id,value为access_token（根据用户id，可以人工废除指定用户全部

token），设置缓存过期时间为7天，保证最终所有token都能删除，请求返回后，客户端缓存此

access_token；

2.使用access_token请求接口资源，校验成功且redis中存在该access_token（未废除）则调用成功；如果

token超时，中间件删除access_token（废除）,同时生成新的access_token并返回。客户端收到新的

access_token，

再次请求接口资源。

3.客户端退出登录或修改密码后，调用中间件注销旧的token(中间件删除access_token（废除）)，同时清

空客户端侧的access_token。

4.以上2 可以增加根据登录时间判断最长X时间必须重新登录，此时则拒绝刷新token。（拒绝的场景：长

时间未登录，频繁刷新）

5.如手机丢失，可以根据手机号人工废除指定用户设备关联的token。

4.0 变动

1.登录

2.登录

3.退出登录

4.修改密码