使用ID4和其他方法通过PKCE安全地获取JWT承载并刷新，以安全地从Blazor Wasm调用API的许多很好的示例……非常有帮助。但是所有样本都说要将JWT存储在本地存储中。这不危险吗？我想是的，但是很想错。
任何人都可以使用浏览器开发工具从本地存储中复制JWt。当然，让JWT短暂存在，但是刷新令牌需要存储在某个地方，所以问题没有解决。当然，API可以具有受众和范围...但是blazor wasm可以从任何来源调用API。当然，ID提供程序的证书使创建带有有效信号的新JWT成为不可能....但是复制的JWT仍然很危险。
React和Angular SPA都存在相同的问题，使用自定义JavaScript库来缓解实时Auth0服务的麻烦，从而缓解该问题。
那么，在API调用之间在客户端上存储JWT的Blazor策略是什么？我们不仅可以注入一个内存单例来将JWT存储为“ App State”对象的一部分吗？这种方法安全吗？还有更好的主意吗？ wasm“内存”相对于本机应用程序具有抗黑客攻击的能力吗？
答案 0 :(得分：1)
好的，这就是我们想出的。评论表示赞赏。
因此，我们要添加自己的自定义标头和TOTP（定时一次性密码）。共享密钥将在登录时获取，并且仅存储在Wasm内存中。这仍然不是完美的，但是我们会对其进行很多混淆。
与Wasm存储器中存储的短暂JWT相比，我们从上面看到的唯一大优势是，我们不必花时间重新编码或改写脚手架JWT行为。
次要的次要优点是TOPT的开销比JWT刷新周期的开销小。
但是...我们很乐意听到一个更聪明的人提出的更好的主意！希望这对您有所帮助。
p.s。我们主要关心的不是XSS也不是中间人。这是类似这样的重播攻击...说我们是小物品的批发商，这些小物品非常有价值，而且很容易在黑市上出售。合法的客户员工用户在工作时登录，并使用浏览器开发工具复制JWT。她还复制了订购某些产品的后负载。她通过电子邮件将其发送给自己。 （她不是主要罪犯）。她回家，激发邮递员，更改收货地址。 （我们的API架构并不是真的很弱，但是现在就说）。她点击了send，我们的API下了订单，按她的工作计费，但运到她的家庭住址。 （再次，她不是主要罪犯。）这是我们要避免的主要情况。
我们还担心假冒恶意软件“ VPN”的重播，但这只是一个MiM，与JWT的本地存储无关。一个令人高兴的巧合是，TOTP也会使我们从这种威胁中受益很多。