试图了解在为 MVC 后端和 API 后端设置授权中间件方面的确切差异。
我的理解（基本）是一个用 [Authorize] 属性修饰的控制器会调用一个授权处理程序来验证客户端的身份，然后
1) 在 MVC 后端，如果未通过身份验证失败，将重定向到默认登录页面，用户将在其中输入其凭据等。
2) 在 API 返回的情况下，控制器将简单地响应 401 消息（重定向在 API 和客户端中没有意义，例如 SPA 必须弄清楚下一步该做什么）
我想问一下在启动类中设置应用程序构建器时存在哪些差异，因为我认为授权中间件的功能因每种情况而异（一种情况重定向，而另一种情况没有）。
附：我知道 MVC 案例通常会使用 cookie，而 API 案例将是 JWT，但想知道在哪里处理/配置重定向或不重定向的决定？
【问题讨论】：
标签： asp.net-core
如果使用app.UseAuthorization()向应用程序添加授权中间件，并在控制器/动作上应用Authorize属性意味着控制器/动作需要登录用户，如果用户未通过身份验证，则身份验证模式将受到挑战。 MVC 和 web api 没有不同的逻辑。
MVC 会重定向是因为你添加了 cookie 身份验证：
services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie();
CookieAuthenticationDefaults.AuthenticationScheme 传递给AddAuthentication 为应用设置了默认的认证方案，所以如果用户没有被认证，就会触发cookie认证，而Account/Login是Cookie认证的默认登录路径，所以用户会被重定向到那个网址。
在 web api 方面，如果您也添加 cookie 身份验证，您将重定向到相同的路径，但通常 Web API 是一种服务，没有任何 UI 元素。因此，重定向 URL 等功能不适用于 Web API。此外，包括单页应用程序 (SPA) 和非浏览器客户端在内的各种客户端都可以使用 Web API。所以我们通常使用 JWT 不记名认证。如果用户未通过身份验证，JWT 不记名身份验证将返回 401，并且不会（也没有意义）在 web api 中重定向。
【讨论】：