В чем разница аутентификации и авторизации

Что проверяют

Различаете ли вы два шага на уровне кода, а не только определений: где в ASP.NET Core заканчивается одно и начинается другое. Следом обычно спрашивают, чем 401 отличается от 403 и почему важен порядок middleware.

Как отвечать

Аутентификация отвечает на вопрос «кто это», авторизация на вопрос «что ему можно». Идентификация стоит ещё раньше: пользователь называет себя (логин), а аутентификация проверяет, что он действительно тот, за кого себя выдаёт (пароль, токен, сертификат).

В ASP.NET Core это разные подсистемы:

• аутентификация: AddAuthentication() со схемой (cookie, JwtBearer, OpenID Connect). Middleware UseAuthentication() разбирает запрос и заполняет HttpContext.User, то есть ClaimsPrincipal с набором claims;
• авторизация: AddAuthorization() и UseAuthorization(), решение принимается по claims. Атрибут [Authorize], роли [Authorize(Roles = "Admin")], политики через AddPolicy и собственные IAuthorizationHandler для правил вроде «редактировать заказ может только его автор»;
• ответы: не прошёл аутентификацию, получает 401 (Challenge), прошёл, но прав не хватает, получает 403 (Forbid).

Порядок в конвейере важен: UseAuthentication() вызывается до UseAuthorization(), иначе на этапе проверки прав пользователь ещё анонимен.

Хороший штрих: сказать, что авторизация не всегда требует входа. [AllowAnonymous] и политика по умолчанию (FallbackPolicy) определяют, что доступно анониму, так что права проверяются и у гостя.

Где спотыкаются

Путают 401 и 403. Сервис, который на запрос без прав отдаёт 401, заставляет клиента заново логиниться, хотя дело вовсе не в сессии.

Считают, что JWT сам по себе и есть авторизация. Токен лишь подтверждает личность и несёт claims, решение о доступе к конкретному ресурсу всё равно принимает сервер, и проверку владельца записи никто за вас не сделает.

Проверяют права только на клиенте: прячут кнопку в интерфейсе и оставляют эндпоинт открытым. Защищать нужно API: [Authorize] на контроллере и проверка ресурса в обработчике.