前言
如题，本节我们进入jwt最后一节内容，jwt本质上就是从身份认证服务器获取访问令牌，继而对于用户后续可访问受保护资源，但是关键问题是：访问令牌的生命周期到底设置成多久呢？见过一些使用jwt的童鞋会将jwt过期时间设置成很长，有的几个小时，有的一天，有的甚至一个月，这么做当然存在问题，如果被恶意获得访问令牌，那么可在整个生命周期中使用访问令牌，也就是说存在冒充用户身份，此时身份认证服务器当然也就是始终信任该冒牌访问令牌，若要使得冒牌访问令牌无效，唯一的方案则是修改密钥，但是如果我们这么做了，则将使得已授予的访问令牌都将无效，所以更改密钥不是最佳方案，我们应该从源头尽量控制这个问题，而不是等到问题呈现再来想解决之道，刷新令牌闪亮登场。
refreshtoken
什么是刷新令牌呢？刷新访问令牌是用来从身份认证服务器交换获得新的访问令牌，有了刷新令牌可以在访问令牌过期后通过刷新令牌重新获取新的访问令牌而无需客户端通过凭据重新登录，如此一来，既保证了用户访问令牌过期后的良好体验，也保证了更高的系统安全性，同时，若通过刷新令牌获取新的访问令牌验证其无效可将受访者纳入黑名单限制其访问，那么访问令牌和刷新令牌的生命周期设置成多久合适呢？这取决于系统要求的安全性，一般来讲访问令牌的生命周期不会太长，比如5分钟，又比如获取微信的accesstoken的过期时间为2个小时。接下来我将用两张表来演示实现刷新令牌的整个过程，可能有更好的方案，欢迎在评论中提出，学习，学习。我们新建一个http://localhost:5000的webapi用于身份认证，再新建一个http://localhost:5001的客户端，首先点击【模拟登录获取toen】获取访问令牌和刷新令牌，然后点击【调用客户端获取当前时间】，如下：
接下来我们新建一张用户表（user）和用户刷新令牌表（userrefreshtoken），结构如下：
如上可以看到对于刷新令牌的操作我们将其放在用户实体中，也就是使用ef core中的back fields而不对外暴露。接下来我们将生成的访问令牌、刷新令牌、验证访问令牌、获取用户身份封装成对应方法如下：
当用户点击登录，访问身份认证服务器，登录成功后我们创建访问令牌和刷新令牌并返回，如下：
此时我们回到如上给出的图，我们点击【模拟登录获取token】，此时发出ajax请求，然后将返回的访问令牌和刷新令牌存储到本地localstorage中，如下：
此时我们再来点击【调用客户端获取当前时间】，同时将登录返回的访问令牌设置到请求头中，代码如下：
客户端请求接口很简单，为了让大家一步步看明白，我也给出来，如下：
好了到了这里我们已经实现模拟登录获取访问令牌，并能够调用客户端接口获取到当前时间，同时我们也只是返回了刷新令牌并存储到了本地localstorage中，并未用到。当访问令牌过期后我们需要通过访问令牌和刷新令牌去获取新的访问令牌，对吧。那么问题来了。我们怎么知道访问令牌已经过期了呢？这是其一，其二是为何要发送旧的访问令牌去获取新的访问令牌呢？直接通过刷新令牌去换取不行吗？有问题是好的，就怕没有任何思考，我们一一来解答。我们在客户端添加jwt中间件时，里面有一个事件可以捕捉到访问令牌已过期（关于客户端配置jwt中间件第一节已讲过，这里不再啰嗦），如下：
通过如上事件并捕捉访问令牌过期异常，这里我们在响应头添加了一个自定义键act，值为expired，因为一个401只能反映未授权，并不能代表访问令牌已过期。当我们在第一张图中点击【调用客户端获取当前时间】发出ajax请求时，如果访问令牌过期，此时在ajax请求中的error方法中捕捉到，我们在如上已给出发出ajax请求的error方法中继续进行如下补充：
到了这里我们已经解决如何捕捉到访问令牌已过期的问题，接下来我们需要做的则是获取刷新令牌，直接通过刷新令牌换取新的访问令牌也并非不可，只不过还是为了安全性考虑，我们加上旧的访问令牌。接下来我们发出ajax请求获取刷新令牌，如下：
发出ajax请求获取刷新令牌的方法我们传入了一个函数，这个函数则是上一次调用接口访问令牌过期的请求，点击【调用客户端获取当前时间】按钮的ajax请求error方法中，最终演变成如下这般：
接下来则是通过传入旧的访问令牌和刷新令牌调用接口换取新的访问令牌，如下：
如上通过传入旧的访问令牌验证并获取用户身份，然后验证刷新令牌是否已经过期，如果未过期则创建新的访问令牌，同时更新刷新令牌。最终客户端访问令牌过期的那一刻，通过刷新令牌获取新的访问令牌继续调用上一请求，如下：
到这里关于jwt实现刷新token就已结束，自我感觉此种实现刷新令牌将其存储到数据库的方案还算可取，将刷新令牌存储到redis也可行，看个人选择吧。上述若刷新令牌验证无效，可将访问者添加至黑名单，不过是添加一个属性罢了。别着急，本节内容结束前，还留有彩蛋。
entityframework core back fields深入探讨
无论是看视频还是看技术博客也好，一定要动手验证，看到这里觉得上述我所演示是不是毫无问题，如果阅读本文的你直接拷贝上述代码你会发现有问题，且听我娓娓道来，让我们来复习下back fields。back fields命名是有约定dei，上述我是根据约定而命名，所以千万别一意孤行，别乱来，比如如下命名将抛出如下异常：
上述我们配置刷新令牌的back fields，代码如下：
要是我们配置成如下形式，结果又会怎样呢？
此时为了解决这个问题，我们必须将其显式配置成back fields，如下：
在我个人著作中也讲解到为了性能问题，可将字段进行tolist()，若进行了tolist()，必须显式配置成back fields，否则获取不到刷新令牌导航属性，如下：
或者进行如下配置，我想应该也可取，不会存在性能问题，如下：
这是关于back fields问题之一，问题之二则是上述我们请求获取刷新令牌中，我们先在刷新令牌的back fields中移除掉旧的刷新令牌，而后再创建新的刷新令牌，但是会抛出如下异常：
我们看到在添加刷新令牌时，用户id是有值的，对不对，这是为何呢？究其根本问题出在我们移除刷新令牌方法中，如下：
我们将查询出来的导航属性并将其映射到_userrefreshtokens字段中，此时是被上下文所追踪，上述我们查询出存在的刷新令牌并在跟踪的刷新令牌中进行移除，没毛病，没找到原因，于是乎，我将上述方法修改成如下看看是否必须需要主键才能删除旧的刷新令牌：
倒没抛出异常，创建了一个新的刷新令牌，但是旧的刷新令牌却没删除，如下：
至此未找到问题出在哪里，当前版本为2.2，难道不能通过back fields移除对象？这个问题待解决。
总结
本节我们重点讲解了如何实现jwt刷新令牌，并也略带讨论了ef core中back fields以及尚未解决的问题，至此关于jwt已结束，下节开始正式进入docker小白系列，感谢阅读。
到此这篇关于详解asp.net core web api之jwt刷新token的文章就介绍到这了,更多相关asp.net core web api jwt刷新token内容请搜索www.887551.com以前的文章或继续浏览下面的相关文章希望大家以后多多支持www.887551.com！
