使用Open ID Connect实现单点登录时是否需要IDistributedCache？

核心结论 #

你的场景不需要额外配置持久化缓存，用户登录状态和蓝绿部署的兼容性，核心不在缓存，而在Cookie密钥的一致性。

一、OIDC中间件的默认逻辑与用户登录状态 #

• 用户登录状态完全由浏览器中的认证Cookie决定：Cookie里存储的是经过加密的认证票据（ClaimsPrincipal），只要Cookie未过期、未被篡改，且服务端能解密，用户就会保持登录状态。本地环境的观察是准确的，和内存缓存无关。
• AddOpenIDConnect()内置的缓存仅用于存储IDP的元数据（如授权端点、令牌端点）和签名密钥，这些内容是全局的，和单个用户会话无关，默认用内存缓存足够，且缓存时间较长，不会因为蓝绿部署的实例切换影响用户登录。

二、蓝绿部署的关键注意点 #

蓝绿部署时用户不会随机登出的前提是：两套环境使用相同的Cookie加密密钥。

• 因为Cookie是服务端加密后发给浏览器的，只要蓝绿实例共用同一组加密/解密密钥，就能互相识别对方生成的Cookie。如果密钥不共享，用户切换到另一套实例时，Cookie无法被解密，就会被要求重新登录。
• 这和持久化缓存无关，只需要在配置中将DataProtection的密钥存储到共享位置（如共享文件系统、密钥管理服务），或者手动指定相同的密钥即可。

三、需要持久化缓存的场景 #

只有当你涉及以下需求时，才需要配置Microsoft.Identity.*包中的持久化缓存：

• 调用下游API：需要缓存用户的AccessToken、RefreshToken，避免频繁向IDP发起令牌请求。此时可以用分布式缓存（如Redis）配合令牌缓存组件实现。
• 自定义会话数据：如果除了OIDC的认证票据，你还在内存中存储了用户的自定义会话信息（比如临时偏好设置），蓝绿切换时会丢失这类数据，这时需要将其存入分布式缓存。
• IDP元数据/密钥的高频更新：如果你的IDP元数据或签名密钥频繁变动，且实例重启频繁导致每次都要重新拉取元数据，可配置ConfigurationManager使用分布式缓存来缓存这些全局数据，减少对IDP的请求。

四、关于AddOpenIDConnect()的缓存配置 #

AddOpenIDConnect()本身没有直接暴露缓存配置项，因为默认的元数据/密钥缓存是内置的内存缓存。如果要替换为分布式缓存，需要自定义ConfigurationManager，示例代码如下：

services.AddOpenIdConnect(options =>
{
    // 其他基础配置...
    var configManager = new ConfigurationManager<OpenIdConnectConfiguration>(
        options.MetadataAddress,
        new OpenIdConnectConfigurationRetriever(),
        new HttpDocumentRetriever())
    {
        RefreshInterval = TimeSpan.FromHours(24) // 自定义缓存刷新间隔
    };
    options.ConfigurationManager = configManager;
});

但这属于优化项，不是你的场景必须的。

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