ASP.NET Core Identity 闲置数分钟后自动登出问题排查

本地运行正常、发布到共享托管环境后闲置数分钟自动登出，核心原因基本都是ASP.NET Core Data Protection 密钥未做持久化配置，少数情况是Cookie配置缺失、托管环境IIS默认配置导致：

• 本地IIS/开发环境运行时，Data Protection默认将认证Cookie的加密密钥存储在当前用户的本地配置目录中，应用重启后密钥不丢失，配置的30天Cookie有效期可以正常生效
• 共享托管环境下，站点通常运行在低权限用户上下文，默认没有可持久化存储密钥的路径，密钥会直接存在应用进程内存中。一旦应用池闲置回收、进程重启、站点自动切换节点，内存中的密钥就会被清空，之前下发的所有认证Cookie无法被解密，系统会直接判定用户未登录，跳转回登录页
• 绝大多数托管商的IIS应用池默认空闲超时为5~20分钟，刚好匹配“闲置数分钟自动登出”的现象。

1. 配置Data Protection密钥持久化 #

这一步是必做项，将密钥存储在站点自身的可写目录下，不受进程重启、应用池回收影响。将以下代码加到Program.cs中，位置要放在认证、Identity相关服务注册之前：

// 需提前引入命名空间：using Microsoft.AspNetCore.DataProtection;
builder.Services.AddDataProtection()
    // 密钥存在站点根目录下的data-protection-keys文件夹
    .PersistKeysToFileSystem(new DirectoryInfo(Path.Combine(builder.Environment.ContentRootPath, "data-protection-keys")))
    // 固定应用名，避免同服务器下多站点密钥冲突
    .SetApplicationName("替换为你的站点唯一标识，比如MyBlogSite");

部署后需要给data-protection-keys文件夹开放IIS运行账户（通常为IIS_IUSRS用户组）的读写权限，否则密钥写入失败会回退到内存存储模式，问题依旧存在。

2. 补全Cookie认证的缺失配置 #

当前的Cookie配置缺少几个关键项，修改后完整配置如下：

builder.Services.ConfigureApplicationCookie(options =>
{
    options.AccessDeniedPath = "/503";
    options.ExpireTimeSpan = TimeSpan.FromDays(30);
    options.LoginPath = "/Index";
    // 新增以下配置
    options.SlidingExpiration = true; // 开启滑动过期，用户每次访问自动续期Cookie有效期
    options.Cookie.HttpOnly = true; // 禁止前端JS读取Cookie，降低XSS窃取风险
    options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest; // 适配托管环境HTTPS反代，避免HTTPS站点下Cookie被拦截
    options.Cookie.SameSite = SameSiteMode.Lax; // 兼容主流浏览器SameSite策略，避免Cookie被浏览器拒收
    options.Cookie.IsEssential = true; // 标记认证Cookie为必要Cookie，避免GDPR中间件默认清除非必要Cookie导致登出
});

注意：当前代码里的AddAuthentication写法不完整，如果没有调用AddIdentity/AddDefaultIdentity方法自动注册认证方案，需要补全Cookie认证的注册逻辑：

builder.Services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(); // 认证相关配置已经通过ConfigureApplicationCookie统一设置，这里不用重复写

3. 托管环境IIS配置适配 #

如果你有托管商的IIS管理权限，可以同步调整应用池配置优化体验：

• 将应用池**空闲超时（Idle Time-out）**设置为0，或者和你的Cookie有效期对齐（比如30天=43200分钟），避免闲置时自动回收进程
• 将应用池**固定回收间隔（Regular Time Interval）**设置为0，或者配置在凌晨低峰期定时回收，避免默认29小时随机回收影响用户体验
  如果没有IIS配置权限也没关系，只要完成第一步的Data Protection密钥持久化，就算应用池回收，重启后站点依然可以读取到历史密钥解密原有Cookie，不会触发自动登出。

4. 负载均衡场景额外处理 #

如果托管商用了多节点负载均衡，要么开启粘性会话保证同一用户的请求始终转发到同一个节点，要么将Data Protection密钥存储在所有节点都能访问的共享位置（比如共享目录、分布式缓存），保证所有节点用同一套密钥加解密Cookie。

配置发布后，登录站点等待超过之前触发自动登出的闲置时长再访问，或者手动在托管面板回收一次应用池后刷新页面，如果不需要重新登录就说明配置生效。

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