多客户端架构下JWT与刷新令牌存储最优方案（Blazor、MAUI、GraphQL）

针对你的ASP.NET Core + Blazor WASM + .NET MAUI架构，结合GraphQL单端点限制，推荐以下分层优化的令牌存储与认证方案：

一、客户端差异化令牌存储策略 #

根据Web与原生客户端的安全特性，分别设计存储方案，兼顾安全与兼容性：

Blazor WASM客户端 #

• 刷新令牌：存储在HttpOnly、Secure、SameSite=Lax的Cookie中，由浏览器自动携带到GraphQL请求，彻底规避XSS窃取风险。
• 访问令牌：存储在Blazor提供的ProtectedSessionStorage中（加密的会话级存储），相比普通localStorage/sessionStorage，即使遭遇XSS攻击，窃取到的也是加密数据，无法直接使用。页面刷新后若访问令牌丢失，自动调用GraphQL刷新令牌操作恢复。

.NET MAUI客户端 #

• 继续使用平台原生的SecureStorage存储访问令牌与刷新令牌：该组件会将数据存入iOS Keychain、Android Keystore等系统级安全容器，原生平台下风险极低，且跨Windows/iOS/Android完全兼容。

二、复用GraphQL单端点实现令牌刷新 #

无需新增独立刷新端点，在现有GraphQL schema中新增refreshToken mutation，统一处理Web与原生客户端的刷新请求：

type Mutation {
  refreshToken(refreshToken: String): AuthPayload
}

type AuthPayload {
  accessToken: String!
  refreshToken: String # 仅返回给MAUI客户端，Web端通过Cookie更新
}

• Web端请求：调用refreshToken时无需在请求体传刷新令牌，服务端直接从HttpOnly Cookie中提取验证；验证通过后，生成新的访问令牌返回给客户端，同时更新Cookie中的刷新令牌（实现令牌旋转）。
• MAUI端请求：调用refreshToken时在请求体传入旧刷新令牌，服务端验证后返回新的访问令牌与刷新令牌，客户端将新令牌更新到SecureStorage中。

三、优化服务端令牌校验性能 #

针对刷新令牌校验的数据库负载问题，通过缓存优化：

• 将刷新令牌的核心状态（有效性、关联用户ID、过期时间）存入Redis缓存，缓存有效期设置为略短于刷新令牌有效期（比如29天）。
• 校验刷新令牌时优先查询缓存，缓存命中则直接验证；缓存失效时再查询数据库，并同步更新缓存，大幅降低数据库访问频率。
• 访问令牌采用JWT无状态校验，无需查询数据库，保持高性能。

四、补充安全增强细节 #

1. 令牌旋转策略：每次刷新生成全新的刷新令牌，将旧令牌标记为失效存入黑名单（可结合Redis缓存黑名单，设置过期时间与旧令牌有效期一致），防止泄露后的令牌被重复利用。
2. Web端Cookie配置：生产环境务必开启Secure=true（仅HTTPS传输）、SameSite=Lax（防范CSRF），并设置合理的路径（如/graphql）。
3. 客户端自动重试：在客户端封装GraphQL请求拦截器，捕获401未授权错误，自动触发refreshToken操作，获取新令牌后重试原请求，对用户完全透明。

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