为何生产环境不建议使用InMemory operational store？

提出替换建议的根本原因 #

InMemory operational store 从设计初衷上就是为本地开发、功能调试场景提供的轻量化实现，没有面向生产环境需要的可靠性、一致性、可扩展性做架构层面的设计匹配。生产环境的身份认证服务是全系统的核心访问入口，对授权状态的一致性、服务可用性、数据持久性的要求远高于内存存储的能力边界，这才是建议强制替换的核心逻辑——你之前梳理的重启后所有用户需重新登录、需要依赖粘性会话的问题，本质都是这种定位不匹配带来的典型表现，而非可以通过简单配置优化解决的bug。

已梳理问题之外的其他潜在风险 #

• 令牌撤销与登出逻辑存在安全漏洞：内存存储的授权标记仅在当前实例本地生效，当用户在某一实例触发登出、主动撤销刷新令牌时，该撤销状态仅会写入当前实例的内存区，其他服务实例无法感知。此时用户持有的已被标记为失效的刷新令牌，只要请求落到未存储该撤销标记的实例上，仍可正常换取新的访问令牌，直接绕过服务端的登出/撤销校验，存在越权使用的安全风险。
• 依赖异步状态的授权流程完全失效：IdentityServer 中基于操作存储实现的设备码授权、CIBA 推送授权、自定义令牌交换等流程，都存在"状态生成-异步等待用户确认-带状态校验"的长链路逻辑。多实例部署时，初始请求如果落到实例A生成了关联状态的授权凭证，后续的用户确认、轮询校验请求落到其他实例时，因为其他实例的内存中没有该状态记录，会直接返回"授权凭证无效"的错误，导致这类授权流程完全不可用。
• 授权权限的一致性无法保障：当运维侧需要动态调整用户的授权范围、强制注销特定用户的会话时，基于内存存储的多实例架构下，各实例维护的授权快照是相互隔离的。你在某一实例上完成的权限更新、会话注销操作，无法同步到其他实例，会出现部分实例仍保留旧的授权判断逻辑、允许已被收回权限的用户正常访问的越权问题。
• 实例异常的业务影响被大幅放大：如果认证服务进程因为OOM、异常崩溃、版本升级发生重启，不光内存中的所有授权记录会直接丢失，且如果重启时恰逢内存中积压了大量未到过期时间的会话、令牌记录，会直接触发全量用户的重新登录，相当于一次普通的服务重启就会造成全平台级别的用户体验波动。
• 内存占用无可靠的边界控制：虽然内置的内存存储会运行定时过期清理任务，但清理任务存在固定的执行窗口期，高并发流量下大量新增的会话、令牌记录会在窗口期内快速堆入进程内存，单进程的内存占用会随在线用户数线性上涨。如果没有提前设置进程内存阈值，极端情况下会直接触发操作系统的OOM保护机制，将认证服务进程强制杀死。

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