我正在制作一个相当简单的 Angular 应用程序，它需要几个不同级别的身份验证，我遇到了 JSON Web 令牌作为实现此功能的一种方式。
我已经阅读了几个地方，以缩短令牌的生命周期以提高安全性，但是，如果用户在令牌过期时仍然登录并积极访问网站怎么办？
我想我也可以在访问令牌的同时添加某种刷新令牌，但这会不会做太多不必要的工作？
我想我只是想知道 JWT 被广泛采用的程度，以及使用一些有状态的身份验证方法是否对我的应用程序更好。其他热门网站如何处理令牌过期问题？
【问题讨论】：
标签： angular security authentication jwt
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，它也有免费实现。
【讨论】：