JWT存储到HttpOnly Cookie相关问题及ASP.NET Core配置咨询

问题1解答 #

你代码中expires=Thu, 1 Jan 1990 12:00:00 UTC的配置是remove方法用来删除Cookie的标准写法，给Cookie设置一个过去的过期时间，浏览器就会自动清理对应Cookie，这个用法是正确的。

关于是否必须设置Cookie过期时间，分场景判断：

• 不设置expires/max-age属性的Cookie属于会话Cookie，会在用户关闭浏览器时自动销毁，适合需要关闭浏览器即自动登出的业务场景。
• 建议你将Cookie的过期时间和内部存储的JWT、刷新令牌本身的过期时间对齐：比如accessToken有效期15分钟，对应Cookie就设15分钟过期；refreshToken有效期7天，对应Cookie就设7天过期，避免Cookie长期存储已经失效的无用令牌。

注意：你当前的AppCookieService用前端JavaScript操作Cookie的实现，完全无法实现你之前提到的HttpOnly Cookie的安全优势。HttpOnly属性是后端在Set-Cookie响应头中指定的，加了该属性的Cookie前端JS完全无法读取、修改，从根源上避免XSS窃取令牌的风险，你当前的Cookie操作逻辑和存LocalStorage没有本质安全区别，建议调整为后端写Cookie的方案。

问题2解答 #

登出时额外调用后端接口吊销对应令牌是更优的安全实践，原因如下：

• 当前你只清理前端存储的令牌，要是攻击者已经提前窃取到了用户未过期的accessToken或refreshToken，即使用户主动登出，攻击者依然可以拿着未过期的令牌访问后端接口，直到令牌自然过期。
• 标准实现是后端维护一个刷新令牌黑名单，登出时前端调用吊销接口，后端将当前用户的refreshToken加入黑名单，后续用该refreshToken请求刷新、访问接口时都会被直接拒绝。如果你的业务安全要求极高，也可以将未过期的accessToken同时加入黑名单校验。
• 如果你的业务安全优先级不高、accessToken有效期设置得极短（比如3-5分钟），也可以权衡开发成本选择不做吊销逻辑，但从安全规范角度，调用吊销接口是推荐做法。

问题3解答 #

你当前贴出的IdentityServer4配置默认只支持从Authorization请求头中提取Bearer JWT做校验，不会自动校验Cookie，如果你要切换为HttpOnly Cookie存储JWT的方案，需要做对应调整：

1. 首先修改后端登录/刷新令牌接口，返回响应时用Set-Cookie头将accessToken、refreshToken写入前端Cookie，必须追加HttpOnly、Secure（生产环境必须开启HTTPS）、SameSite=Strict属性，防范XSS和CSRF攻击。
2. 调整认证配置，让JWT认证组件支持从Cookie中提取令牌：可以给AddIdentityServerAuthentication配置对应的事件，在收到请求时优先从Cookie中读取accessToken，读取不到再从请求头提取。
3. 如果你直接使用IdentityServer4内置的会话Cookie机制，不需要手动管理JWT存储，IdentityServer会自动完成Cookie有效性、会话状态的校验，不需要额外开发校验逻辑。

注意：你当前配置中的RequireHttpsMetadata = false仅可用于本地开发，生产环境必须改为true，否则HTTP传输过程中令牌容易被中间人窃听。

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