Как атрибут [Authorize] узнает, что пользователь проходит аутентификацию в ASP.NET MVC, с помощью токена аутентификации?

Question

Хотелось бы узнать, как атрибут [Authorize] распознает, что этот пользователь аутентифицирован?

Если пользователь действителен, то мы вызываем метод FormsAuthentication.SetAuthCookie(), а в соответствии с MSDN этот метод:

Создает билет проверки подлинности для предоставленного имени пользователя и добавляет его в коллекцию файлов cookie ответа или в URL, если вы используете проверку подлинности без файлов cookie.

Проверяет атрибут [Authorize]билет для проверки подлинности или коллекция файлов cookie?

Answer 1

[Authorize] не имеет отношения к какому-либо механизму аутентификации. Он просто ищет в пользователях IIdentity флаг IsAuthenticated. Также будет проверен метод IsMemberOf пользователей для авторизации на основе ролей.

Вся работа по декодированию билета аутентификации выполняется на ранних этапах конвейера приложения, который устанавливает эти флаги. К моменту вызова методов атрибута авторизации вся эта работа уже выполнена и сохраняется в пользовательских данных времени выполнения.

Вы можете легко проверить исходный код атрибута Authorize, и вы увидите, что он довольно прост по своей природе. Он просто возвращает true или false, основываясь на некоторых простых поисках.

Это стало сложнее в ядре .net, где оно основано на политиках, а что нет, но оригинальная реализация MVC была довольно простой.

Answer 2

Мой ответ касается ядра ASP.NET. Я не уверен, что вы спрашивали о классическом ASP.NET, но это должно быть похоже.

Есть промежуточное ПО, которое вы должны добавить, чтобы [Authorize] заработало. ASP.NET Core предоставляет это промежуточное ПО из коробки, и вы также можете добавить свои собственные обработчики аутентификации.

Вы можете проверить, как это реализовано, прочитав: https://github.com/aspnet/Security/tree/dev/src

Например, если вы хотите использовать аутентификацию канала-носителя JWT, вам нужно добавить промежуточное программное обеспечение канала-носителя JWT, это просто расширение AuthenticationBuilder : https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication.JwtBearer/JwtBearerExtensions.cs, которое вызывает AddScheme под капотом.

Вы хотите использовать аутентификацию на основе файлов cookie, просто позвонив по номеру AddCookie, который также является расширением, которое вызывает AddScheme под капотом: https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication.Cookies/CookieExtensions.cs

Использование здесь задокументировано: https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/identity-2x?view=aspnetcore-2.1

См. Также Использование атрибута [Authorize]

Веб-API предоставляет встроенный фильтр авторизации AuthorizeAttribute. Этот фильтр проверяет, прошел ли пользователь аутентификацию. Если нет, то возвращается код состояния HTTP 401 (неавторизованный) без вызова действия.

Если вам интересно, как этот фильтр работает под капотом, вы можете проверить его здесь .

Прежде чем авторизоваться, вы должны пройти аутентификацию, за это отвечает логика: https://github.com/aspnet/Security/blob/644f34e90d35b369efdce9c11ab1db42e0a7f4a7/src/Microsoft.AspNetCore.Authorization.Policy/PolicyEvaluator.cs#L91

В итоге

как атрибут [Authorize] знает, что этот пользователь аутентифицирован.

Один атрибут Authorize не знает, аутентифицирован ли этот пользователь. Это обрабатывается промежуточным программным обеспечением для аутентификации и строго зависит от схемы, с которой оно пытается аутентифицироваться. Он просто пытается аутентифицироваться с помощью схем, которые вы добавили (cookie, jwt и т. и устанавливает HttpContext.User из результата ClaimsPrincipal, который просто является результатом обработчика схемы, например, jwt handler . Я думаю, что это должно дать вам более глубокое представление о том, как это работает.

---

Как правило, если вы начинаете новый проект, я не рекомендую использовать классический ASP.NET и готовиться к будущему с .NET Core, так как сейчас все идет в этом направлении. ASP.NET 5 (я также называю его «классическим») в настоящее время практически мертв.