如何为现有Blazor WASM应用添加Google认证（搭配ASP.NET Core 8 Web API）

一、手动JWT认证流程的安全性与OpenIddict替代建议 #

当前方案的安全性评估 #

你的手动JWT认证流程逻辑通顺，但存在几个关键安全隐患：

• localStorage存储风险：localStorage易受XSS攻击，恶意脚本可直接窃取存储的token与刷新token。建议优先考虑将刷新token存入HttpOnly Cookie（由Web API设置，避免前端操作），access token可存在内存中而非持久化存储。
• token校验完整性：仅校验token有效期不够，需确保同时验证签名、issuer、audience等核心字段，防止伪造token绕过校验。
• 刷新token防护：需实现刷新token的一次性使用机制，即刷新后立即作废旧的刷新token，避免被窃取后重复利用。

是否应改用OpenIddict #

强烈建议替换为OpenIddict，核心原因：

• 减少安全漏洞：OpenIddict实现了OAuth2.0/OpenID Connect标准流程，内置token签名、加密、过期管理等安全机制，避免手动实现时的疏漏。
• 降低维护成本：无需自行编写登录、刷新、token校验等重复逻辑，后续扩展认证方式（如第三方登录）更便捷。
• 合规性与兼容性：遵循官方认证标准，与.NET生态深度集成，社区支持完善，排查问题更高效。

二、Google SSO方案的可行性分析 #

你设计的Google SSO流程整体可行，但有两处关键优化点：

• 改用授权码流替代直接获取IdToken：不要让Wasm直接接收IdToken，应让用户跳转至Google授权页，授权成功后Google将授权码返回至Web API的回调端点，再由Web API向Google换取IdToken与Access Token。此方式避免IdToken在前端暴露，降低窃取风险。
• 强化Token验证与用户创建逻辑：Web API验证Google Token时，需调用Google官方验证端点校验签名、issuer、audience等字段；创建用户时，以Google返回的唯一标识（如sub字段）作为用户关联依据，避免重复创建账号。
• token存储优化：返回的刷新token应存入HttpOnly Cookie，access token可存在Blazor WASM的内存中，减少前端存储带来的安全风险。

内容的提问来源于stack exchange，提问作者J. Lawliet