我在Angular.js应用程序中使用JWT进行身份验证，在服务器端使用Express.js。
基本上，当用户登录时，会创建一个新令牌（使用https://github.com/auth0/node-jsonwebtoken）并发送回客户端。如果令牌在客户端也是有效的（angular.js部分，使用https://github.com/auth0/angular-jwt），则会创建一个新用户并将令牌存储在cookie中。
因此，对服务器上某个路径的每个请求都受到令牌验证的保护。但是，我的令牌有一个到期时间。现在让我们说为了论证，到期时间是30秒;用户可以主动使用我的应用程序30秒，之后，他会被注销。这并不完全是用户友好的。
所以我所做的就是每次向服务器发出请求时，我都会创建一个新令牌并将其发送回响应头。当我在Angular.js客户端收到响应时，我读取了令牌并覆盖了cookie中的令牌。这样，只要客户端处于活动状态（或者更确切地说，向服务器端发出请求），令牌就会刷新。
现在我想知道以下内容：
感谢您的时间和回复！
答案 0 :(得分：3)
是的，这是一种有效的方法。这与许多人采取的方法相同， 包括流行的Angular模块ng-token-auth。你可能会 考虑将令牌保存到本地存储，并回退到 如果浏览器不支持cookie存储（请参阅 http://caniuse.com/#feat=namevalue-storage用于报道）。
我会做你所描述的。
一种解决方案是使用$interval基本上ping API。你需要做的就是发送一个令牌来获得一个新的（即在你现在的标题中）。跟踪您发送的“ping”数量。您可以根据ui-router的$stateChangeSuccess（即导航到新视图）或您喜欢的任何内容（包括提交表单或其他非ping请求）等特定操作重置“ping”的数量。当“ping”的数量达到阈值时，警告用户他们的会话即将到期，并在延迟之后擦除存储的令牌并将其注销。检查您的ping响应是否存在来自API的身份验证错误，表明用户可能需要注销和/或重定向。
也许你只需要30秒作为代码生命周期的示例。我建议您更接近您想要的浏览会话超时。作为参考，请考虑Ruby gem devise_token_auth默认为2周，.NET defaults默认为10小时。您的需求可能会有所不同。
答案 1 :(得分：0)
使用刷新令牌也解决了这个问题。您的访问令牌的生命周期很短，并通过签名进行验证。刷新令牌具有更长的使用寿命，用于获取新的访问令牌。
当刷新令牌用于获取新的访问令牌时，这是进行额外检查的好时机：刷新令牌是否已被撤销？此用户帐户是否仍然有效？
这两个令牌都可以存储在安全的cookie中，并在每次请求时提供。这样做可以让您的服务器在需要时透明地使用刷新令牌，并在cookie响应中设置新的访问令牌。
这是我们为Express-Stormpath采取的方法，并记录在文档的Authentication部分。如果您想卸载身份验证图层，我建议Stormpath。 （免责声明：我在那里工作，写了那个模块）。