使用OpenId与Cookie认证时多生命周期配置合理性咨询

核心矛盾点分析 #

你的当前配置存在几个明显的逻辑冲突，会导致用户体验和安全性问题：

1. Token生命周期逻辑倒挂
   access token设为14天、refresh token仅60分钟的配置完全违背OAuth2的设计初衷。refresh token的作用是在access token失效时获取新凭证，正常逻辑下它的有效期应该长于access token，或者至少能覆盖用户的活跃周期。现在的配置会导致用户登录60分钟后，refresh token失效，哪怕access token还有13天有效期，也无法通过刷新获取新的access token，必须重新登录，14天的access token完全失去意义。

2. 票据与Cookie生命周期不匹配
   Cookie设为会话级（浏览器关闭即失效），但认证票据配置了14天绝对过期+60分钟滑动过期。这意味着：

• 用户只要关闭浏览器，哪怕票据还在有效期内，Cookie也会丢失，必须重新登录，滑动过期和14天绝对过期的配置根本无法发挥作用；
• 如果用户持续活跃，60分钟滑动过期会刷新票据有效期，但Cookie还是会话级，一旦浏览器重启，会话依然丢失。

3. 应用池回收的影响
   这部分是没问题的：因为你用了基于SQL Server的分布式ITicketStore，票据存储在外部数据库而非应用内存，所以IIS应用池24小时回收不会丢失用户会话，新进程可以正常从数据库读取票据。

调整建议 #

1. 修正Token生命周期配置

• 缩短access token有效期：遵循安全最佳实践，把access token设为短周期（比如60分钟），降低凭证泄露的风险；
• 延长refresh token有效期：将refresh token设为7-14天，同时开启认证提供商的refresh token滑动刷新（如果支持）。这样用户在活跃时，每次用refresh token获取新access token时，会同步得到新的refresh token，持续延长会话有效期，避免频繁登录。

2. 对齐票据与Cookie的生命周期

根据你的业务需求选择两种模式：

• 持久会话（记住我）：
  • 将Cookie设置为持久Cookie，有效期和票据的绝对过期时间一致（比如14天）；
  • 保留票据的60分钟滑动过期配置，确保用户活跃时，Cookie和票据的有效期同步刷新；
  • 代码中需要在认证时设置IsPersistent = true（比如在ChallengeAsync的AuthenticationProperties中添加该属性）。
• 会话级会话：
  • 移除票据的绝对过期和滑动过期配置，或者将其设为会话级；
  • 保持Cookie的会话级设置，用户关闭浏览器即结束会话。

3. 优化票据存储逻辑

• 确保ticket.Properties.ExpiresUtc的取值与你期望的会话有效期一致（比如和refresh token的有效期对齐）；
• 滑动过期的时间建议和access token的有效期匹配（比如都是60分钟），这样在access token快过期时，自动触发refresh操作，同时刷新票据的滑动有效期。

补充说明 #

在Blazor Server中，会话Cookie存储在浏览器的会话存储内是合理的，但要注意：会话存储是浏览器级别的，标签页关闭后不会丢失，但浏览器关闭后会清空，所以如果需要跨浏览器重启保持会话，必须使用持久Cookie（存储在本地存储）。

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