IdentityServer4重启后OIDC客户端有效会话仍被重定向登录的配置问题

当前异常属于Cookie认证Scheme配置错位导致的，和OperationalStore的存储实现无直接关系，具体原因如下：

• IdentityServer处理/connect/authorize这类交互授权端点时，会强制使用内置的交互Cookie Scheme（默认常量值为idsrv）校验用户登录态，不会读取全局默认认证Scheme的Cookie内容。
• 现有代码中，在AddIdentityServer()之后独立调用AddAuthentication()注册了自定义Cookie Scheme，同时覆盖了IdentityServer原本设置的全局默认认证Scheme。这种配置下：
  • 你的登录逻辑实际写入的是自定义Scheme的Cookie，仅能支持IdentityServer自身的MVC页面（如登录、授权管理页）识别登录态，因此服务重启后访问IdS管理页无需重新登录。
  • connect/authorize端点尝试读取内置idsrv Scheme下的登录Cookie时，永远无法匹配到实际写入的登录票据，因此触发重定向到登录页。
• 你观察到的“未重启时功能正常、重启后异常”的现象，本质是未重启时内存中残留的IdentityServer交互临时状态缓存，暂时掩盖了Scheme不匹配的问题；服务重启后临时缓存清空，配置错位的问题直接暴露。
• 关于“OperationalStore无数据入库”的错觉，属于概念认知偏差：OperationalStore（无论内存还是数据库实现）仅存储授权码、刷新令牌、参考令牌、用户授权同意记录这类服务端侧的授权流程数据，完全不存储用户的浏览器登录会话。用户登录态由浏览器端的加密Cookie承载，和OperationalStore的存储实现无关。这也是你切换InMemoryPersistedGrants方案后，异常行为完全一致的原因。

• 移除手动独立注册Cookie认证的代码块，不要自行调用AddAuthentication().AddCookie()。IdentityServer会自动注册内置的交互Cookie Scheme（idsrv）作为全局默认Scheme，无需手动初始化。
• 如需自定义Cookie的SameSite、SecurePolicy等属性，需要将配置应用到IdentityServer内置的Cookie Scheme上，而非新建独立Scheme，正确配置方式如下：

// 对IdentityServer内置的默认Cookie Scheme做自定义配置
services.PostConfigure<CookieAuthenticationOptions>(IdentityServerConstants.DefaultCookieAuthenticationScheme, options =>
{
    options.Cookie.SameSite = Microsoft.AspNetCore.Http.SameSiteMode.None;
    options.Cookie.SecurePolicy = Microsoft.AspNetCore.Http.CookieSecurePolicy.Always;
});

• 如果你必须使用自定义Cookie Scheme作为IdentityServer的交互登录载体，需要在AddIdentityServer()初始化时显式指定Scheme名称，打通两端映射：

services.AddIdentityServer(options =>
{
    // 将内置交互Cookie Scheme替换为你的自定义Scheme
    options.Authentication.CookieScheme = identityServerConfig.GetCookieSchemeOrDefault();
    options.Authentication.CookieLifetime = TimeSpan.FromHours(10);
})
// 后续接入现有OperationalStore、InMemory资源、客户端等原有配置

• 验证现有EF Core迁移已正确创建OperationalStore对应的数据库表，无需调整OperationalStore的现有配置。
• 额外核对：你当前的授权请求response_type=code搭配code_challenge属于授权码+PKCE流程，并非你描述的隐式流程，需确认客户端配置的AllowedGrantType与实际请求流程一致，避免后续出现其他兼容问题。

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