Dotnet Core+Angular Cookie认证及避免客户端存储Token的方案咨询

• Cookie安全配置必须做满：Cookie强制开启HttpOnly属性禁止前端JS读写，规避XSS窃取风险；同步开启Secure属性仅允许HTTPS传输，SameSite默认设为Lax，若有跨站需求调整为None时必须配套完整CSRF防护；Cookie有效期需和服务端存储的AccessToken有效期绑定，避免超长有效期Cookie被滥用。
• 服务端Token存储选型要适配部署架构：不要将Token存在服务端内存，否则多实例部署会话不互通、服务重启会话全部失效，建议用Redis这类分布式缓存存储，Key和用户会话ID绑定，Value存储AccessToken、RefreshToken、过期时间等信息，缓存过期时间和Token本身有效期对齐；缓存服务必须做好访问权限控制，禁止公网暴露，避免Token批量泄露。
• Identity Server4客户端配置要同步调整：原PKCE的公开客户端需改为授权码流的机密客户端（Confidential Client），配置正确的客户端密钥，重定向URI指向托管Angular的ASP.NET Core服务回调地址，关闭PKCE校验、禁止浏览器端直接获取Token，Scope按需配置资源API权限和offline_access（需RefreshToken能力时开启）。
• 转发代理要做安全限制：服务端处理API转发前，必须先校验用户Cookie对应的会话有效性，未登录直接拦截跳转登录；严格限制转发目标地址仅为自有资源服务器地址，避免被利用为公开代理；转发时强制覆盖Authorization请求头，仅注入服务端存储的对应Token，忽略前端传入的任何身份凭证头。
• CSRF防护不能省略：Cookie认证天然存在CSRF风险，所有修改类请求（POST/PUT/DELETE等）必须开启ASP.NET Core自带的Antiforgery校验，可在Angular首屏加载时将CSRF Token注入前端全局变量，前端请求时携带在自定义请求头中，服务端校验通过后再执行转发逻辑。
• 登出逻辑要做全链路处理：用户登出不能仅清除前端Cookie，需同步执行三个操作：删除分布式缓存中对应会话的Token数据、调用IS4的登出接口清除授权中心会话、清除用户认证Cookie；若接入了单点登出能力，需做好IS4的登出回调处理，保证同授权体系下的其他应用同步登出。

• 无感Token续期：服务端可封装转发逻辑，每次转发API请求前先判断AccessToken剩余有效期，若低于预设阈值（比如5分钟），直接用存储的RefreshToken向IS4申请新Token，更新缓存后再用新Token转发请求，全程前端无感知，无需额外处理过期逻辑。
• 用官方组件做转发降低成本：不要自己手写HttpClient转发逻辑，直接采用ASP.NET Core官方的YARP反向代理组件，性能远高于自研转发逻辑，同时原生支持路由规则配置、请求头修改、熔断限流等能力，减少重复开发。
• 用户声明前置透传：若Angular前端需要用到用户名、角色、头像这类非敏感用户信息，可在服务端返回Angular首屏HTML时，直接将声明序列化后注入页面全局变量，前端初始化时直接读取，无需额外发起接口请求获取用户信息。
• 异常兜底优化：转发请求若收到资源服务器返回的401状态码，不要直接返回给前端，先校验是否为AccessToken过期导致，是则先触发续期逻辑，续期成功后自动重试一次请求，重试失败再跳转登录；若返回403则直接透传给前端提示权限不足即可。
• 会话管控能力增强：可在后台实现用户会话列表功能，支持用户查看当前登录的所有设备/会话，主动踢掉异常会话，只需删除对应缓存的Token即可立即生效，无需调整IS4侧配置，用户账号安全管控更灵活。

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