Какие сервисы и зависимости добавляет метод AddAuthentication в ASP.NET Core?

Question

Какие сервисы и зависимости добавляет метод AddAuthentication в ASP.NET Core?

Тип вопроса: ASP.NET Core Вероятность: 25% Категория: C# Разработчик

Ответ

Метод расширения AddAuthentication, вызываемый в ConfigureServices, регистрирует в DI-контейнере фундаментальные сервисы, необходимые для работы подсистемы аутентификации. Он не добавляет конкретные схемы (провайдеры), а подготавливает инфраструктуру для них.

Основные добавляемые сервисы:

IAuthenticationService — основной сервис, обрабатывающий логику аутентификации (например, HttpContext.AuthenticateAsync).
IAuthenticationSchemeProvider — управляет зарегистрированными схемами аутентификации (Cookie, JWT Bearer, OAuth и т.д.).
IAuthenticationHandlerProvider — отвечает за создание обработчиков для конкретных схем.
IAuthenticationRequestHandler — для схем, которые могут обрабатывать запросы самостоятельно (например, OAuth-редиректы).

Типичный паттерн использования:

public void ConfigureServices(IServiceCollection services)
{
    // 1. Добавляем базовые сервисы аутентификации и настраиваем схемы по умолчанию
    services.AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    })
    // 2. Добавляем конкретные обработчики (провайдеры) аутентификации
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "my-issuer",
            ValidateAudience = true,
            ValidAudience = "my-audience",
            ValidateLifetime = true
        };
    })
    .AddCookie("SecondaryCookieScheme"); // Можно добавить несколько схем

    services.AddControllers();
}

public void Configure(IApplicationBuilder app)
{
    // 3. Включаем middleware аутентификации в конвейер обработки запроса
    // Важно: UseAuthentication() должен идти ДО UseAuthorization() и ПОСЛЕ UseRouting()
    app.UseRouting();
    app.UseAuthentication(); // <-- Активирует зарегистрированные сервисы
    app.UseAuthorization();
    app.UseEndpoints(endpoints => endpoints.MapControllers());
}

Ключевой момент: Без вызова AddAuthentication последующий вызов UseAuthentication() в конвейере не будет иметь эффекта, а атрибуты вроде [Authorize] и методы HttpContext.User не смогут корректно идентифицировать пользователя.

Ответ 18+ 🔞

Так, слушай сюда, про этот твой AddAuthentication. Это ж, блядь, как фундамент для дома, а не сам дом, понимаешь?

Ну вот представь: ты вызываешь services.AddAuthentication(). Все думают: "О, сейчас нам JWT-токены или куки подкинет!" А нихуя подобного, ёпта! Этот метод не добавляет ни одного конкретного провайдера — ни JWT Bearer, ни Cookie, ни OAuth. Вообще нихуя!

Что он делает на самом деле? Он завозит в твой DI-контейнер обслуживающий персонал, блядь. Без них вся система аутентификации — пизда рулю.

Вот главные мудаки, которых он регистрирует:

IAuthenticationService — это главный по тарелкам, начальник охраны. Именно он, сука, когда ты вызываешь HttpContext.AuthenticateAsync(), бегает, ищет, кто из обработчиков за эту схему отвечает, и выдаёт тебе ClaimsPrincipal. Без него — нихуя не аутентифицируешь.
IAuthenticationSchemeProvider — это архивариус, блядь. Он ведёт учёт всех зарегистрированных схем: "Так, у нас есть схема 'JwtBearer', есть 'Cookies', а вот это 'GoogleOAuth'". Когда система спрашивает "а какую схему использовать по умолчанию?", это он отвечает.
IAuthenticationHandlerProvider — мастер на все руки, поставщик кадров. Ему говорят: "Мне нужен обработчик для схемы 'Cookie'". А он такой: "На, держи, только что с завода". Создаёт экземпляр нужного хендлера.
IAuthenticationRequestHandler — это для особых, хитрожопых схем, которые могут перехватить запрос сами. Например, OAuth-провайдер, который ловит редирект с кодом. Без этой абстракции они бы не смогли встроиться в конвейер.

Как это всё, блядь, собирается в кучу? Смотри, классика жанра:

public void ConfigureServices(IServiceCollection services)
{
    // 1. БАЗА. Регистрируем обслуживающий персонал (сервисы) и назначаем дефолтных шерифов.
    services.AddAuthentication(options =>
    {
        // Если не указано явно, то для аутентификации и вызова челленджа используем JWT.
        options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    })
    // 2. ПРОДАВЦЫ. А вот теперь подключаем конкретных "продавцов" доверия.
    .AddJwtBearer(options => // Этот чувак будет проверять токены в заголовке Authorization
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "my-issuer",
            ValidateAudience = true,
            ValidAudience = "my-audience",
            ValidateLifetime = true
        };
    })
    .AddCookie("SecondaryCookieScheme"); // А этот — следить за куками. Можно много кого добавить!

    services.AddControllers();
}

public void Configure(IApplicationBuilder app)
{
    app.UseRouting();

    // 3. ПОСТАНОВКА НА ПОСТ. Включаем мидлварь аутентификации в конвейер.
    // ВАЖНО, БЛЯДЬ: ставим ПОСЛЕ UseRouting() (чтобы знать, куда идём) и ОБЯЗАТЕЛЬНО ДО UseAuthorization().
    app.UseAuthentication(); // <-- Вот тут наш "начальник охраны" выходит на работу.
    app.UseAuthorization();  // <-- А этот уже решает, пускать ли аутентифицированного юзера дальше.

    app.UseEndpoints(endpoints => endpoints.MapControllers());
}

И главный вывод, который ты должен вынести, как охуенный урок: если не вызвать AddAuthentication, то потом твой app.UseAuthentication() будет просто так висеть в конвейере, как хуй с горы — бесполезно. Атрибут [Authorize] будет срать ошибками, HttpContext.User останется пустым, и ты будешь чесать репу, думая, что накосячил с токенами, а проблема-то в том, что ты забыл завезти базовую инфраструктуру, ебанашка!

Вот так вот, просто и с примерами.