Авторизация с помощью определенной схемы в ASP.NET Core

Общие сведения о схемах проверки подлинности см. в разделе "Общие сведения о ASP.NET Core аутентификации: схема проверки подлинности".

В некоторых сценариях, таких как одностраничные приложения (SPAs), обычно используются несколько методов проверки подлинности. Например, приложение может использовать cookieпроверку подлинности на основе на основе проверки подлинности для входа пользователя в приложение и установления удостоверений и Bearer проверки подлинности (часто использующих JWTs) для запросов на основе JavaScript к конечным точкам веб-API. В некоторых случаях приложение может иметь несколько экземпляров обработчика проверки подлинности. Например, приложение имеет два cookie обработчика, где один содержит базовое удостоверение и создается при активации многофакторной проверки подлинности (MFA). MFA может быть активирован, так как пользователь запрашивал операцию, требующую дополнительной безопасности.

Для следующего AddAuthentication вызова без указанной схемы проверки подлинности по умолчанию в приложение добавляются два обработчика проверки подлинности, используя имена схем проверки подлинности по умолчанию:

• Cookie (имя схемы: "Cookies"): AddCookie
• JWT носителя (имя схемы: "Bearer"): AddJwtBearer

builder.Services.AddAuthentication()
    .AddCookie(options =>
    {
        options.LoginPath = "/Account/Unauthorized/";
        options.AccessDeniedPath = "/Account/Forbidden/";
    })
    .AddJwtBearer(options =>
    {
        options.Audience = "http://localhost:5001/";
        options.Authority = "http://localhost:5000/";
    });

services.AddAuthentication()
    .AddCookie(options => {
        options.LoginPath = "/Account/Unauthorized/";
        options.AccessDeniedPath = "/Account/Forbidden/";
    })
    .AddJwtBearer(options => {
        options.Audience = "http://localhost:5001/";
        options.Authority = "http://localhost:5000/";
    });

Указание схемы по умолчанию при вызове AddAuthentication приводит к настройке HttpContext.User свойства для этого ClaimsPrincipal удостоверения. Если это поведение не нужно, вызовите бессерверную форму AddAuthentication, как показано в предыдущем примере.

JWT Пакет NuGet носителя

В нескольких примерах этой статьи используется API в пакетеMicrosoft.AspNetCore.Authentication.JwtBearer NuGet. Пакет предоставляет ПО промежуточного слоя, которое упрощает проверку подлинности веб-маркераJWT JSON, обеспечивая безопасную проверку подлинности для API и веб-служб.

Выбор схемы с атрибутом [Authorize]

Приложение может указать обработчик проверки подлинности для Razor компонентов, минимальных конечных точек API, контроллеров, методов действий, Razor Pages и PageModels путем передачи списка схем проверки подлинности с разделителями-запятыми в [Authorize] атрибут. Атрибут задает схемы проверки подлинности независимо от того, настроена ли схема по умолчанию. В следующем примере Cookies задаются схемы проверки подлинности (CookieAuthenticationDefaults.AuthenticationScheme) и Bearer (JwtBearerDefaults.AuthenticationScheme) .

Razor Для компонента:

@attribute [Authorize(AuthenticationSchemes = 
    CookieAuthenticationDefaults.AuthenticationScheme + "," + 
    JwtBearerDefaults.AuthenticationScheme)]

Для конечной точки Минимального API украсите конструктор с AuthorizeAttribute помощью схемы:

app.MapGet("/api/data", [Authorize(AuthenticationSchemes = 
    CookieAuthenticationDefaults.AuthenticationScheme + "," + 
    JwtBearerDefaults.AuthenticationScheme)] () =>
{
    ...
});

Кроме того, можно передать схемы с помощью пользовательской политики:

app.MapGet("/api/data", () =>
{
    ...
})
.RequireAuthorization(policy => 
    policy.AddAuthenticationSchemes(
        CookieAuthenticationDefaults.AuthenticationScheme + "," + 
        JwtBearerDefaults.AuthenticationScheme));

Для контроллера MVC:

[Authorize(AuthenticationSchemes = AuthSchemes)]
public class MixedAuthSchemesController : Controller
{
    private const string AuthSchemes = 
    CookieAuthenticationDefaults.AuthenticationScheme + "," + 
    JwtBearerDefaults.AuthenticationScheme;

    ...
}

PageModel Для класса:

[Authorize(AuthenticationSchemes = 
    CookieAuthenticationDefaults.AuthenticationScheme + "," + 
    JwtBearerDefaults.AuthenticationScheme)]
public class MixedAuthSchemesModel : PageModel
{
    ...
}

ПО промежуточного слоя авторизации утверждает доступ с любой из указанных схем в указанном порядке. Если обе схемы проходят проверку подлинности пользователя (допустимый cookie и допустимый маркер носителя), ПО промежуточного слоя авторизации объединяет удостоверения в один ClaimsPrincipal контекст.

Указав одну схему, соответствующий обработчик запускается. В следующем примере для конечной точки игнорируются только обработчик со Bearer схемой, а все cookieудостоверения на основе:

@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Authentication.JwtBearer
@attribute [Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]

Выбор схемы с политикой авторизации

Если вы предпочитаете указать требуемые схемы в политике, задайте AuthenticationSchemes коллекцию при добавлении политики.

В следующем примере политика выполняется только с удостоверением, Over18 созданным обработчиком JWT носителя (JwtBearerDefaults.AuthenticationScheme). Пример класса, используемого MinimumAgeRequirement в следующем примере, см. в разделе "Авторизация на основе политик" в ASP.NET Core. Метод RequireAuthenticatedUser применяет проверку подлинности пользователей к конечным точкам, где применяется политика.

builder.Services.AddAuthorizationBuilder()
    .AddPolicy("Over18", policy =>
    {
        policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
        policy.RequireAuthenticatedUser();
        policy.Requirements.Add(new MinimumAgeRequirement(18));
    });

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Over18", policy =>
    {
        policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
        policy.RequireAuthenticatedUser();
        policy.Requirements.Add(new MinimumAgeRequirement(18));
    });
});

services.AddAuthorization(options =>
{
    options.AddPolicy("Over18", policy =>
    {
        policy.AuthenticationSchemes.Add(JwtBearerDefaults.AuthenticationScheme);
        policy.RequireAuthenticatedUser();
        policy.Requirements.Add(new MinimumAgeRequirement());
    });
});

Используйте политику, задав параметр AuthorizeAttribute.Policy.

Razor Для компонента:

@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "Over18")]

Для конечной точки Минимального API вызовите RequireAuthorization имя политики:

app.MapGet("/api/data", () => 
{
    ...
})
.RequireAuthorization("Over18");

Для контроллера MVC:

[Authorize(Policy = "Over18")]
public class RegistrationController : Controller

PageModel Для класса:

[Authorize(Policy = "Over18")]
public class MixedAuthSchemesModel : PageModel
{
    ...
}

[Authorize] Взаимодействие схемы атрибутов и схемы политик

Схемы авторизации для конечной точки с одним или несколькими Authorize атрибутами и одной или несколькими схемами на основе политикобъединяются , чтобы задать окончательный набор разрешенных схем для конечной точки. Это создает объединение, и любая указанная схема может пройти проверку подлинности запроса. Атрибут, добавляющий файлы cookie в политику, ограниченную Bearer проверкой подлинности, позволяет cookieзапрашивать только запрос, при условии, что cookie создается ClaimsPrincipal соответствие требованиям политики.

Использование нескольких схем проверки подлинности

Для некоторых приложений требуется поддержка нескольких методов проверки подлинности. Типичный сценарий включает принятие JWT носителя, выданных несколькими поставщиками удостоверений.

В схеме JwtBearerDefaults.AuthenticationSchemeпроверки подлинности по умолчанию зарегистрирован только один JWT обработчик носителя. Зарегистрируйте дополнительные JWT схемы носителя для дополнительных поставщиков удостоверений с уникальными именами схем проверки подлинности. В следующем примере называется вторая схема "MEID" для издателя ME-ID.

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Audience = "https://localhost:5000/";
        options.Authority = "https://localhost:5000/identity/";
    })
    .AddJwtBearer("MEID", options =>
    {
        options.Audience = "https://localhost:5000/";
        options.Authority = 
            "https://sts.windows.net/00001111-aaaa-2222-bbbb-3333cccc4444/";
    });

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.Audience = "https://localhost:5000/";
        options.Authority = "https://localhost:5000/identity/";
    })
    .AddJwtBearer("MEID", options =>
    {
        options.Audience = "https://localhost:5000/";
        options.Authority = 
            "https://sts.windows.net/00001111-aaaa-2222-bbbb-3333cccc4444/";
    });

Обновите политику авторизации по умолчанию, чтобы принять обе схемы проверки подлинности:

var defaultAuthorizationPolicyBuilder = new AuthorizationPolicyBuilder(
    JwtBearerDefaults.AuthenticationScheme, "MEID");

defaultAuthorizationPolicyBuilder =
    defaultAuthorizationPolicyBuilder.RequireAuthenticatedUser();

builder.Services.AddAuthorizationBuilder()
    .SetDefaultPolicy(defaultAuthorizationPolicyBuilder.Build());

builder.Services.AddAuthorization(options =>
{
    var defaultAuthorizationPolicyBuilder = new AuthorizationPolicyBuilder(
        JwtBearerDefaults.AuthenticationScheme, "MEID");

    defaultAuthorizationPolicyBuilder =
        defaultAuthorizationPolicyBuilder.RequireAuthenticatedUser();

    options.DefaultPolicy = defaultAuthorizationPolicyBuilder.Build();
});

services.AddAuthorization(options =>
{
    var defaultAuthorizationPolicyBuilder = new AuthorizationPolicyBuilder(
        JwtBearerDefaults.AuthenticationScheme, "MEID");

    defaultAuthorizationPolicyBuilder = 
        defaultAuthorizationPolicyBuilder.RequireAuthenticatedUser();

    options.DefaultPolicy = defaultAuthorizationPolicyBuilder.Build();
});

Предыдущий код настраивает авторизацию по умолчанию с поддержкой нескольких схем проверки подлинности:

1. Новый AuthorizationPolicyBuilder инициализирует построитель политик, принимаюющий проверку подлинности из двух схем:

   • JwtBearerDefaults.AuthenticationScheme (JWT маркеры носителя)
   • MEID (настраиваемая схема проверки подлинности для ME-ID, определенная ранее)

   Это означает, что пользователи могут проходить проверку подлинности с помощью JWT маркеров или схемы MEID.

2. RequireAuthenticatedUser вызывается для требования пользователей, прошедших проверку подлинности, для доступа к защищенным конечным точкам.

3. SetDefaultPolicy прицелено к AddAuthorizationBuilder:

   • Регистрирует службы авторизации.
   • Задает эту политику в качестве значения по умолчанию для всех [Authorize] атрибутов, которые не указывают настраиваемую политику. Любая конечная точка, помеченная автоматически, [Authorize] использует эту политику

Результатом использования предыдущего API является то, что защищенные конечные точки в приложении требуют проверки подлинности через JWT маркеры носителя или схему MEID, обеспечивая гибкость в том, как пользователи проходят проверку подлинности.

Выбор схемы политики на основе заголовка Authorization

Инструкции по использованию AddPolicyScheme метода со ForwardDefaultSelector свойством для динамического выбора схемы проверки подлинности для каждого запроса см. в ASP.NET Core схемах политики.

Дополнительные ресурсы

• Многофакторная проверка подлинности в ASP.NET Core
• Защита раздела с помощью MFA (dotnet/AspNetCore.Docs #15791)
• Несколько схем проверки подлинности jwt не могут проверить ключ подписи (dotnet/aspnetcore No 26002)