我正在制作一个相当简单的角度应用程序，它需要几个不同级别的身份验证，并且我遇到了JSON Web令牌作为实现此目的的一种方法。
我已经阅读了多个地方，以使令牌的寿命真正缩短以提高安全性，但是，如果用户仍然登录并在令牌过期时主动访问该站点怎么办？
我想我也可以在访问令牌中添加某种刷新令牌，但这是否比必要的工作量大？
我想我只是想知道JWT的普及程度，以及是否使用某种状态认证方法对我的应用程序会更好。其他热门网站如何处理令牌过期问题？
答案 0 :(得分：1)
JWT确实很受欢迎，但这并不意味着它们是任何工作的最佳工具。首先，有一些简单的有状态网站希望维护用户会话。他们使用Cookie来存储会话ID，一切都很好。然后，API成为一回事，问题是cookie仅发送到它们的来源。如果未将Cookie设置为httpOnly，则Javascript可以读取它，但如果它是Sesaion ID，则在其他api上仍然没有用。因此，需要无状态的东西，本身就是有效的东西，而这正是JWT之类的令牌可以提供帮助的地方，因为Javacript可以访问它并将其发送到任何地方。但是，这样做的代价是要有一定的安全性-首先，跨站点脚本（xss）可以用来窃取令牌，而httpOnly cookie则不可能。
如果您的客户端应用程序（javascript）仅与自己的来源对话（无需与不同域上的api通信），则可以（实际上应该）将身份验证信息存储在httpOnly cookie中。但是，如果您希望服务器应用程序是无状态的，那仍然可以是JWT。如果无论如何它都是有状态的，那么使用JWT并没有多大意义，您可以使用会话ID，这样会更安全。
但是，如果您想要无状态，则JWT是一个不错的选择，因为它得到了广泛的支持，并且是在客户端上存储此类信息的标准方法。在一个众所周知的实现中，它通常也相对安全，因此像往常一样，不要自己动手，否则您将面临诸如正确签名令牌，验证签名，避免重播攻击等挑战。比最初看起来要困难得多。
应根据您的业务案例和相关风险来设置令牌寿命。这始终是一种平衡，最终还是您的决定。它应该是最适合您产品的最短时间，无论它是什么。您只需要注意，攻击者可以使用已破坏的令牌，直到到期后再进行相应的设置。
仅当刷新令牌的存储方式不同时，刷新令牌才有意义。如果也是您的JavaScript存储和访问刷新令牌，那也没有意义，它将以相同的方式受到损害。但是，您可以执行诸如登录服务或端点之类的操作，以创建长期的刷新令牌，将其存储在httpOnly cookie中，并创建一个短暂的JWT以供实际使用。只要JWT过期，您的javascript就可以进入登录端点，并使用cookie获取另一个JWT，直到刷新令牌也过期。这是有道理的，因为攻击者只能通过XSS访问短暂的JWT，并且刷新令牌会更加安全。但是通过这种方式，它正在慢慢演变成一个单点登录，您应该（再次）使用标准算法和实现，例如OpenID Connect，它也具有免费实现。