这问题我刚接触OpenID Connect集成时也懵过，给你把管道里的逻辑掰碎了说清楚：

• OpenID Connect中间件已经悄悄帮你内置了/signin-oidc的处理逻辑
  当你在Program.cs里配置AddOpenIdConnect并指定CallbackPath = "/signin-oidc"时，这个中间件会自动在ASP.NET Core的请求管道中注册该端点的专属处理器——根本不需要你手动写Controller或Action来对应。它的核心作用就是接收Entra ID返回的授权响应（包含授权码、ID Token等），完成令牌验证、用户身份创建这些关键认证步骤，所以请求到这个路径时，管道里已经有对应的处理逻辑了，自然不会返回404。

• 认证流程是自动跳转的，你没察觉到回调环节
  当你首次访问需要认证的页面时，OpenID Connect中间件会自动重定向你到Entra ID的登录页。等你登录成功后，Entra ID会把请求发往/signin-oidc，这时候中间件的内置处理器会在后台完成所有工作：验证令牌合法性、把用户身份信息存入HttpContext，然后自动重定向回你最初访问的页面（也就是你看到的首页）。整个回调过程是中间件自动完成的，浏览器可能只是短暂跳转，所以你没看到/signin-oidc的页面，直接就到了首页。

• CallbackPath的匹配要求，也侧面验证了中间件在正常工作
  你提到的CallbackPath必须和Azure Portal里注册的一致，这点完全正确。如果配置不匹配，Entra ID会直接返回回调地址不匹配的错误，而你现在顺利完成了认证，正好说明中间件的内置/signin-oidc端点在正常接收和处理Entra ID的回调请求。

要是你好奇想验证，可以试试直接在浏览器输入https://yourapp.com/signin-oidc访问这个端点（注意是没经过Entra ID授权的情况），这时候你会看到中间件返回的认证错误，而不是404——这就实锤了这个端点确实是由中间件在处理的。

内容来源于stack exchange