IS4、IS5（Identity Server）版本差异及升级问题咨询

• 官方安全兜底保障缺失的补位：IdentityServer4的免费社区支持已于2022年12月正式终止，后续官方不会再推送任何安全漏洞修复、依赖兼容补丁，生产环境长期运行无安全层面的官方支撑，一旦出现新的协议实现漏洞、依赖组件高危CVE，需要团队自行排障修复，也很难满足等保、行业资质审计的合规要求。
• 适配现代.NET运行时生态：IdentityServer5原生对齐.NET 6/7/8 LTS版本的依赖体系，解决了IS4在高版本.NET环境下的常见兼容问题——很多团队后续升级主应用到高版本.NET时，会遇到IS4绑定的低版本Microsoft.Extensions.*依赖冲突、跨平台部署性能损耗、AOT编译不兼容的问题，IS5直接匹配微软最新的框架依赖版本，不需要额外做依赖降级的hack操作。
• 安全协议能力的升级：IS5补齐了多个新一代身份认证标准的原生支持，包括OAuth 2.0 推送授权请求（PAR）、DPoP令牌合规校验、OIDC动态客户端注册接口的安全加固，同时修复了IS4中已被社区发现的协议实现偏差，不需要团队针对这些新安全标准自行二次开发扩展。
• 代码迭代的持续更新通道：IS4对应的开源分支已经停止所有新特性合并，后续所有的bug修复、性能优化、体验改进都会全量落在IS5的代码线上，停留在IS4版本意味着永久失去后续的迭代收益。

• 授权规则带来的硬成本变化：IS4开源阶段遵循宽松的Apache 2.0协议，商业场景无授权门槛；但IS5当前的开源授权规则仅面向个人开发者、非营利类项目免费，达到团队规模、营收门槛的商业使用场景，需要采购对应商业授权，这是很多中小企业升级时最直接的决策阻力。
• 破坏性接口变更带来的迁移工作量：IS5没有做完全的向后兼容，旧版IS4中的IProfileService、IClientStore等核心扩展接口的方法签名有调整，团队自定义的令牌生成逻辑、Claims映射规则、客户端仓储实现，都需要逐行适配新的接口定义；部分旧的Cookie认证方案、回调端点也被标记为废弃，甚至基于IS4定制的登录、授权页面，因为路由结构调整也会出现表单提交404的问题，需要同步调整前端跳转逻辑、后端的令牌校验中间件参数，迁移过程如果没有完整的测试用例覆盖，很容易出现认证流程中断的线上故障。
• 存量自定义扩展的适配风险：很多基于IS4开发的二次模块，比如旧版的授权码持久化实现、自定义密码校验逻辑、对接旧版AD/LDAP的适配组件，都是基于IS4旧的事件管道模型开发的，IS5调整了中间件执行顺序，部分旧的事件回调（比如令牌签发事件）的触发时机、传入参数结构有变化，如果没有熟悉原有逻辑的开发人员接手，很容易出现自定义逻辑不生效、令牌生成异常的问题。

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