Blazor应用OAuth JWT Bearer Token存储最佳实践咨询

每次调用第三方API前都重新请求令牌，不是OAuth 2.0客户端凭证（M2M）流的行业规范做法，属于冗余实现，你担心的大规模推广触发令牌端点限流是必然会出现的问题，必须做令牌缓存+过期校验。

• 绝大多数第三方OAuth服务对令牌端点的限流阈值远低于普通业务接口，高频请求令牌不仅容易触发限流，还可能被判定为异常流量被临时封禁。
• 每次业务调用多一次令牌请求的HTTP往返，会平白增加接口响应延迟，没有任何实际收益。
• OAuth2协议本身设计access_token带过期时间的目的，就是为了让客户端在有效期内复用令牌，减少授权端点的压力。

你担心本地存储令牌带来XSS风险是合理的，但风险本质来自「存储位置不对」，不是缓存令牌本身的问题。只要把令牌存在用户浏览器无法触达的位置，完全可以规避这类风险，尤其你用的是无用户参与的M2M鉴权，令牌代表的是应用本身的调用权限，不需要随用户会话存在客户端侧。

首先明确一条不可逾越的安全红线：绝对不要把client_secret存储在Blazor WebAssembly（WASM）的前端代码中——WASM代码会完整下发到用户浏览器，任何人都可以反编译拿到你的密钥，直接冒充你的应用调用第三方API。

根据你的Blazor托管模式，对应实现方式如下：

• 如果你用的是Blazor Server（所有业务逻辑运行在服务端，浏览器仅接收UI渲染更新）
  • 令牌全程存储在服务端即可，根本不需要下发到浏览器，完全不存在XSS窃取令牌的可能。
  • 服务端直接使用.NET自带的IMemoryCache做单实例部署的令牌缓存，多实例部署就换用Redis这类分布式缓存。
  • 缓存键可以按第三方API的目标资源标识设置，缓存内容存储access_token和接口返回的过期时间戳，缓存过期时间设置为比令牌实际过期时间早3-5分钟，预留缓冲时间避免时钟偏移、网络抖动导致拿到刚好过期的令牌。
  • 每次调用第三方API前先读缓存：缓存命中且未临近过期就直接复用令牌；缓存不存在或临近过期时，再调用令牌端点拿新令牌写入缓存，之后再发起业务请求。
• 如果你用的是Blazor WASM（逻辑运行在用户浏览器端）
  • 绝对不要在前端直接对接第三方令牌端点、存储令牌。你需要在自己的服务端搭建一层薄的代理接口，由服务端持有client_id、client_secret，按照上面Blazor Server的逻辑完成令牌获取、缓存、过期刷新的全流程。
  • 前端WASM只调用你自己的服务端代理接口，由代理层转发请求到第三方API，前端全程接触不到第三方的Bearer Token，从根源上避免XSS窃取令牌、密钥泄露的问题。

避坑提醒：不要试图在WASM端用localStorage、sessionStorage、IndexedDB存储M2M令牌，这类存储可以被页面上任意运行的JavaScript读取，只要出现一个XSS漏洞，攻击者就能直接拿走令牌冒用你的应用权限。

内容的提问来源于stack exchange，提问作者paulpitchford