在 Blazor 客户端 Wasm 中存储不记名令牌？策略是什么？

Question

许多很好的示例可以使用 ID4 和其他方法通过 PKCE 安全地获取 JWT 承载，通过刷新，从 Blazor Wasm 安全地调用 API...非常有帮助。但是所有样本都说将 JWT 存储在本地存储中。这不危险吗？我想是的，但很想错。

任何人都可以使用浏览器开发工具从本地存储复制 JWt。当然，让 JWT 短命，但是刷新令牌需要存储在某个地方，所以问题没有解决。当然，API 可以有受众和范围......但是 blazor wasm 可以从任何来源调用 API。当然，ID 提供者证书使创建具有有效 sig 的新 JWT 成为不可能……但复制的 JWT 仍然很危险。

React 和 Angular SPA 存在相同的问题，并且服务实时 Auth0 竭尽全力使用自定义 JavaScript 库来缓解这个问题。

那么，在 API 调用之间将 JWT 存储在客户端上的 Blazor 策略是什么？我们不能只注入一个内存单例来将 JWT 存储为“应用程序状态”对象的一部分吗？这种方法安全吗？有更好的想法吗？ wasm 的“内存”与原生应用程序相比是否具有相当的抗黑客性？

Answer 1

好的，这就是我们想出的。欢迎评论。

• 使用 VS 脚手架解决方案非常好。这样可以节省很多时间。
• 但由于 JWT 存储在会话存储中，因此脚手架解决方案很容易受到重放攻击。

因此，我们添加了带有 TOTP（定时一次性密码）的自定义标头。共享密钥将在登录时获取并仅存储在 Wasm 内存中。这仍然不完美，但我们会对其进行大量混淆。

与存储在 Wasm 内存中的短期 JWT 相比，我们从上面看到的唯一一大优势是我们不必花时间重新编码或覆盖脚手架式 JWT 行为。

第二个小优势是 TOPT 的开销低于 JWT 刷新周期。

但是......我们很想听听一些更聪明的人提出更好的想法！希望这在此期间有所帮助。

附言我们主要关心的不是 XSS 或中间人。这是一个类似这样的重放攻击......假设我们是非常有价值且易于在黑市上出售的小东西的批发商。合法客户员工-用户在工作中登录，并使用浏览器开发工具复制 JWT。她还复制了订购一些产品的帖子有效载荷。她将这些通过电子邮件发送给自己。 （她不是犯罪大师）。她回家，激发邮递员，更改收货地址。 （我们的 API 架构实际上并没有那么弱，只是暂时说是这样）。她点击发送，我们的 API 下订单，向她的工作收费，但运送到她的家庭地址。 （再说一遍，她不是犯罪大师。）这是我们要避免的主要情况。

我们还担心虚假的恶意软件“VPN”重播，但这是 MiM，与 JWT 的本地存储无关。一个令人高兴的巧合是，TOTPs 也会让我们从这种威胁中变得更加坚强。