公开客户端使用Cookie保护Web API的陷阱及ASP.NET Core认证问题咨询

• CSRF跨站请求伪造风险
  ASP Identity默认的Cookie认证依赖浏览器自动携带Cookie的机制，所有访问你服务域名的请求都会自动带上身份凭证，哪怕请求是从第三方恶意网站发起的。如果你的API包含数据修改、账号操作等敏感接口，攻击者很容易通过诱导登录用户访问恶意站点，发起未授权的操作。虽然你可以通过配置AntiForgeryToken做防护，但公开JS客户端（尤其是SPA应用）需要额外做大量前后端适配，跨域场景下防伪标记的传递逻辑会非常复杂，远没有OIDC/PKCE方案中Bearer令牌仅由JS主动携带在Authorization请求头中的天然CSRF防护能力可靠。
• 跨域访问兼容性问题
  现代浏览器对Cookie的SameSite属性有严格限制：如果你的JS客户端和API服务不在完全同根域名下，SameSite设为Strict/Lax时跨域请求无法携带Cookie，设为None则必须强制开启HTTPS，且很多老旧浏览器不兼容该配置。如果你的API需要对接多个不同域名的公开JS客户端，Cookie认证几乎无法落地，而OIDC/PKCE颁发的Bearer令牌不受跨域Cookie策略限制，只要前端主动放在请求头中即可正常验证。
• 公开客户端下的安全边界更脆弱
  公开JS客户端属于无法存储保密信息的不可信客户端，ASP Identity的Cookie默认有效期通常较长，一旦被XSS攻击窃取，攻击者可以长期冒用用户身份。而OIDC/PKCE流程颁发的access_token一般有效期仅为数小时，就算被窃取影响范围也非常有限，还可以通过短有效期+无感刷新的方案平衡安全和体验。
• 扩展能力受限
  ASP Identity的Cookie认证是面向同域Web场景的轻量化方案，本身不支持OIDC协议原生提供的多身份源对接、细粒度Scope权限控制、单点登录/登出、多端统一身份认证、令牌主动吊销等能力。如果你的后续业务需要对接APP、小程序等其他端，或者需要接入第三方身份提供商，Cookie认证方案几乎无法复用，需要整体重构身份体系，而OIDC是全端通用的标准化身份协议，扩展成本极低。

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