我之前刚遇到这个问题，当时我想开始一个项目，让自己写和玩。
一开始只是想用session来解决，后来想为什么不用jwt呢？事实上，这两种方法都可以，但是如果使用session，就会出现分布式问题。如何在多台服务器之间共享一个会话池，可能就是常用的Redis。如果不是后端，也不会尴尬。我主要讲一下我当时想出来的使用jwt的大概流程。
JWT工作原理
jwt的本质是用一点cpu计算时间代替存储空间，相对便宜。它意味着客户端向服务器请求一个令牌，服务器验证客户端可信后，向客户端发出一个唯一的令牌，然后客户端就可以用这个令牌与服务器进行通信，从而建立起两端之间的信任。所以你会发现，只要有这个令牌，不管谁能向服务器发送请求，服务器都会认为是合法的。
了解jwt的工作原理后，很容易回答出主的问题。
在运行时保存令牌
如果你想记录你的登录状态，你必须先登录(废话.).客户端账号密码通过HTTP请求发送到服务器后，服务器验证通过，生成令牌返回给前端，前端可以从HTTP响应中获取令牌。
获得令牌后，我们可以将其保存在一个全局变量中。所有后续请求都将从全局变量中取出这个令牌，然后将其放入请求头中，并将其发送到服务器。
将令牌保存在本地存储中
但是你会发现当我们刷新浏览器的时候，我们已经登录了，但是服务器还是让我们再次登录。这是因为我们将令牌放在了运行时，这意味着令牌的生命周期只会在应用程序开始被销毁时存在，但在刷新后会被清除。
解决这个问题的办法就是让这个令牌持久化。解决方案之一是将其存储在本地存储中。
登录请求成功后，令牌存储在本地存储中。但是，在接下来的一年中，每个请求都会从localstorage中取出令牌，并将其放入请求头中，从而完成令牌持久化，这也是许多应用程序采用的方式。
但这完美吗？不完全是~
如果我们的网站受到xss注入攻击(当然，我们不希望它发生)，对方可以获得localstorage中的所有内容，其中包括token的重要信息。对此我该怎么办？
所以我觉得最好的办法就是用cookie保存token。
用Cookie保存令牌
登录请求成功后，http不需要返回令牌的信息，而是服务器直接设置cookie将令牌直接写入客户端的cookie中。你可能会说，xss注入写在cookie里就不能读吗？不不不，除了设置令牌，我们还要做一件更重要的事情，就是把cookie设置为http-only，这样就可以保证js不能读取cookie信息，有了https，就可以让我们的请求更安全。
使用cookie保存令牌有两个优点：
安全
我们可以确保cookie信息足够安全，不容易被https窃取，并将cookie设置为仅http。
客户不知道。
客户端只知道登录成功，所有后续的请求都不需要任何处理，因为cookie是浏览器自带的，所以我们不需要关心如何处理令牌。使用localstorage有一个问题，就是每当令牌过期时，我们需要重新启动，将新的令牌设置到localstorage中。相反，如果使用cookies，客户端不需要做任何处理。服务器判断令牌已经过期后，直接更新cookies就可以了。
更新令牌
token的一个特点就是一旦生成就无法更改，所以你会发现如果发放有效期为15分钟的token，15分钟后，即使用户已经活动，也会被强制立即启动。实际上，这并不能满足某些应用的需求。
如果我们希望活动用户始终保持登录状态，我们需要在15分钟后尽快重新发出令牌，以延长登录有效期。此时，同一用户将同时有两个有效令牌，因此当我们重新颁发令牌时，我们还需要将即将过期的令牌涂黑，使其无效。
如何黑化令牌
有同学对如何黑化更新token很感兴趣。我简单说一下。
当每个请求进来时，你需要做多少事情？
您是否需要验证令牌(因为某些API可能不需要验证)请求的令牌是否合法(是否过期或被屏蔽)？分析令牌，看看它是否即将过期。如果即将过期(例如，距离过期还有15分钟的时间差)，请重新发出令牌并设置cookie，将当前令牌涂黑，并请求继续。那么如何破解令牌呢？
简单来说，就是用数据库存储要涂黑的令牌，然后在上面的过程中，每次验证令牌的时候，都要检查数据库，看令牌是否涂黑。
但是你会发现数据库中被黑的令牌会越来越多，所以我们也可以打开一个预定的任务来删除数据库中过期的令牌，因为它们已经过期了，不存在被黑的问题。
作者：jsdyl叔叔
链接：https://www.zhihu.com/question/301253397/answer/548334082