ASP.NET Cookie认证场景下未配置UseAuthentication()时，IsAuthenticated被设为true的机制咨询

兄弟，我太懂你现在的疑惑了——按咱们平时对ASP.NET认证流程的认知，UseAuthentication()中间件就是专门干校验Cookie、把HttpContext.User.Identity.IsAuthenticated设为true的活儿，结果你没在中间件管道里加它，第一个自定义中间件里就看到这个值已经是true了，换谁都会一脸懵！

结合你的场景，大概率是这几种情况导致的：

• 你用了ASP.NET Core Identity相关服务
  如果你在Program.cs/Startup.cs里配置了Identity（比如builder.Services.AddDefaultIdentity<IdentityUser>()或者AddIdentity<IdentityUser, IdentityRole>()），这些扩展方法可不止是注册用户角色这么简单——它们会偷偷帮你注册Cookie认证方案，还自动添加了Identity专属的中间件和过滤器。这些组件会在请求流转过程中（甚至可能在你以为的“第一个自定义中间件”之前，或者就在你的中间件执行后、页面处理前），自动调用认证逻辑校验Cookie，直接把HttpContext.User和IsAuthenticated给设置好。
  这里要注意：有时候我们以为自己把自定义中间件加在了最前面，但默认模板里的UseHttpsRedirection、UseStaticFiles、UseRouting这些已经提前注册了，Identity的中间件可能就藏在这些默认步骤里，比你的自定义中间件先执行。

• 间接引入了UseAuthentication()
  有些扩展方法会“暗地”帮你添加UseAuthentication()，比如旧版本里的UseIdentity()（现在已经过时），或者你用的某些第三方库、项目里的自定义扩展方法，里面包含了这个调用。你可以仔细检查下Program.cs/Startup.cs的代码，看看有没有类似的隐藏逻辑——不过按说UseAuthorization()要求UseAuthentication()在它前面，要是没加的话会直接报错，你没碰到报错的话这个可能性就比较小。

• 有没有手动触发过认证逻辑？
  如果你在全局过滤器、自定义服务里手动调用过await HttpContext.AuthenticateAsync("Cookie")这类方法，那也会提前校验Cookie并设置HttpContext.User，哪怕没加UseAuthentication()中间件。不过你说没做过这类操作的话，这个情况基本可以排除。

另外，你可以在自定义中间件里打印一下HttpContext.User的认证方案，看看具体是哪个组件触发的认证，这样能更快定位到根源~

备注：内容来源于stack exchange，提问作者JRoppert