.NET 4.7.2下EPiServer CMS双OpenID Connect AD认证异常问询

核心机制说明 #

你遇到的两个异常现象，完全是Katana（.NET OWIN框架的核心实现）和经典ASP.NET管道的固定设计导致的，不属于配置bug，核心逻辑非常直接：

所有标记为active模式的认证中间件，在应用启动注册时都会自动把自己设为全局默认的认证跳转处理方；如果有多个active中间件，后注册的会直接覆盖前面的配置值。所有没有明确指定要跳转哪个认证方案的未授权请求，都会被这个全局默认的处理方接管，不会自动匹配路径或者注册顺序。

问题1的具体原因 #

你观察到的“同一管道阶段下，最后注册的中间件处理所有请求”的现象，完全匹配上述规则：

• 当只有一个active中间件在认证阶段运行时，没有其他配置覆盖，它自然就是全局默认的认证跳转方，所有未指定方案的未授权请求都会触发它的流程，和你观察到的单中间件行为完全一致。
• 当两个中间件都注册在同一认证阶段时，应用启动会依次执行两个中间件的注册逻辑，后加载的中间件会直接把自己的认证类型设为全局默认值，覆盖前一个中间件的设置。
• 你在web.config里针对/episerver路径配置的授权规则，属于经典ASP.NET的管道授权检查：当检测到未授权访问时，它发起的认证跳转请求不会附带“要跳转到哪个认证服务”的标识，因此会直接被全局默认的那个中间件（也就是最后注册的那个）接管，不存在根据路径自动选择对应中间件的内置逻辑。

问题2的具体原因 #

你观察到的“不同管道阶段下，后注册的中间件触发更早位置的授权检查”的现象，其实和两个中间件的管道运行阶段完全无关，根源依然是配置覆盖逻辑：

• 你对管道阶段的运行顺序认知是正确的：PreRequestHandlerExecute的执行时机确实晚于AuthenticateRequest（也就是你说的authentication管道阶段），但这部分是中间件校验请求身份的执行顺序，和它在应用启动时修改全局默认认证配置的流程是完全独立的。
• 哪怕第二个中间件校验请求身份的逻辑跑的更晚，它在应用启动、注册中间件的那一刻，就已经把自己的认证类型覆盖成了全局默认值。
• 带[Authorize]特性的控制器授权检查，是在MVC管道执行到对应动作时发起的未授权跳转，同样不会附带指定的目标认证方案，因此会触发被设为全局默认的第二个中间件的跳转流程——你原本以为“先注册的active中间件应该优先响应”，本质是误以为中间件的注册顺序会影响授权检查的触发优先级，实际上优先级被全局默认配置的覆盖规则完全接管了。

正确的分流配置方式 #

要实现“后台路径走AD1、前台带角色校验走AD2”的目标，必须绕开全局默认配置的干扰：

• 彻底关闭两个中间件的active模式，将两个OIDC中间件的配置都设置为AutomaticAuthenticate = false、AutomaticChallenge = false，避免它们自动写入全局默认配置、无差别接管所有认证请求。
• 针对不同场景显式指定要使用的认证方案：
  • 针对/episerver的后台访问路径，在检测到未授权访问时，手动发起指向后台AD提供者对应认证类型的跳转
  • 针对需要外部用户角色校验的前台控制器，通过自定义授权过滤器，在触发认证跳转时明确指定使用外部AD提供者对应的认证类型
• 只要所有未授权跳转场景都明确指定目标认证方案，就不会出现非预期的中间件接管问题。

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