различия промежуточного программного обеспечения авторизации между mvc и api

Question

Пытаюсь понять точные различия в настройке промежуточного программного обеспечения авторизации для бэкэнда MVC и бэкэнда API. с атрибутом [Authorize] вызовет обработчик авторизации для проверки личности клиента, а затем

1) В бэкэнде MVC и в случае неудачной попытки аутентификации перенаправить на страницу входа по умолчанию, где использование будет вводить свои учетные данные et c.

2) В случае возврата API контроллер просто ответил бы сообщением 401 (перенаправление не имеет смысла в API и клиенте, SPA например, придется выяснить, что делать дальше)

Я хотел бы спросить, какие различия существуют при настройке конструктора приложений в классе запуска, поскольку я полагаю, что функциональность промежуточного программного обеспечения авторизации различается в зависимости от каждого case (один случай перенаправляет, а другой нет).

PS Я знаю, что * 1 016 * обычно будет использовать cook ie, в то время как случай API будет JWT, но интересно, где решение перенаправить или нет обрабатывается / настраивается?

Answer 1

Если добавить промежуточное ПО для авторизации в приложение с использованием app.UseAuthorization() и применить атрибут Authorize к контроллеру / действию, это означает, что для контроллера / действия требуется авторизованный пользователь, если пользователь не аутентифицирован, схема аутентификации будет оспорена. Нет разных logi c в MVC и веб-api.

MVC перенаправит, потому что вы добавляете повар ie аутентификацию:

services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie();

CookieAuthenticationDefaults.AuthenticationScheme переданный в AddAuthentication устанавливает схему аутентификации по умолчанию для приложения, поэтому, если пользователь не аутентифицирован, запускается аутентификация cook ie, а Account/Login - это путь входа по умолчанию для аутентификации Cook ie, поэтому пользователь будет перенаправлен на этот URL.

На стороне веб-API вы будете перенаправлены на тот же путь, если добавите также аутентификацию cook ie, но обычно веб-API является службой и не имеет каких-либо элементов пользовательского интерфейса. Таким образом, такие функции, как URL-адрес перенаправления, не применяются к веб-API. Более того, веб-API может использоваться различными клиентами, включая одностраничные приложения (SPA) и клиенты, не являющиеся браузерами. Поэтому мы обычно используем аутентификацию носителя JWT. Аутентификация носителя JWT вернет 401, если пользователь не аутентифицирован, и перенаправление в веб-api не будет (и не имеет смысла).