Использовать несколько JWT Bearer Authentication

Вы можете полностью достичь того, чего хотите:

services
    .AddAuthentication()
    .AddJwtBearer("Firebase", options =>
    {
        options.Authority = "https://securetoken.google.com/my-firebase-project"
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "my-firebase-project"
            ValidateAudience = true,
            ValidAudience = "my-firebase-project"
            ValidateLifetime = true
        };
    })
    .AddJwtBearer("Custom", options =>
    {
        // Configuration for your custom
        // JWT tokens here
    });

services
    .AddAuthorization(options =>
    {
        options.DefaultPolicy = new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase", "Custom")
            .Build();
    });

Давайте рассмотрим различия между вашим кодом и этим.

AddAuthentication не имеет параметра

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

Используйте другую перегрузку AddJwtBearer

Каждый метод AddXXX для добавления аутентификации имеет несколько перегрузок:

• Один, в котором используется схема аутентификации по умолчанию, связанная с методом аутентификации, например см. здесь для проверки подлинности файлов cookie
• Один, в котором вы передаете, помимо конфигурации параметров, имя схемы аутентификации как на этой перегрузке

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

Обновите политику по умолчанию

Поскольку запросы больше не будут аутентифицироваться автоматически, добавление атрибутов [Authorize] к некоторым действиям приведет к тому, что запросы будут отклонены, и будет выдан HTTP 401.

Поскольку это не то, что мы хотим, потому что мы хотим дать обработчикам аутентификации возможность аутентифицировать запрос, мы меняем политику системы авторизации по умолчанию, указывая, что схемы аутентификации Firebase и Custom должны быть пытался для аутентификации запроса.

Это не мешает вам быть более строгими в отношении некоторых действий; Атрибут [Authorize] имеет свойство AuthenticationSchemes, которое позволяет вам переопределить, какие схемы аутентификации действительны.

Если у вас есть более сложные сценарии, вы можете использовать авторизация на основе политик. Я считаю, что официальная документация великолепна.

Представим, что некоторые действия доступны только для токенов JWT, выпущенных Firebase, и должны иметь заявку с определенным значением; вы можете сделать это так:

// Authentication code omitted for brevity

services
    .AddAuthorization(options =>
    {
        options.DefaultPolicy = new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase", "Custom")
            .Build();

        options.AddPolicy("FirebaseAdministrators", new AuthorizationPolicyBuilder()
            .RequireAuthenticatedUser()
            .AddAuthenticationSchemes("Firebase")
            .RequireClaim("role", "admin")
            .Build());
    });

Затем вы можете использовать [Authorize(Policy = "FirebaseAdministrators")] для некоторых действий.

И последнее замечание: если вы перехватываете события AuthenticationFailed и используете что-либо, кроме первой политики AddJwtBearer, вы можете увидеть IDX10501: Signature validation failed. Unable to match key.... Это вызвано тем, что система проверяет каждый AddJwtBearer по очереди, пока не найдет совпадение. Обычно на ошибку можно не обращать внимания.

Это продолжение ответа Микаэля Дерри.

В нашем приложении есть настраиваемое требование авторизации, которое мы решаем из внутреннего источника. Мы использовали Auth0, но переходим на аутентификацию учетной записи Microsoft с использованием OpenID. Вот слегка отредактированный код из нашего запуска ASP.Net Core 2.1. Для будущих читателей это работает на момент написания этой статьи для указанных версий. Вызывающий использует id_token из OpenID для входящих запросов, переданных как Bearer token. Надеюсь, это поможет кому-то другому, пытающемуся преобразовать полномочия личности, так же, как этот вопрос и ответ помогли мне.

const string Auth0 = nameof(Auth0);
const string MsaOpenId = nameof(MsaOpenId);

string domain = "https://myAuth0App.auth0.com/";
services.AddAuthentication()
        .AddJwtBearer(Auth0, options =>
            {
                options.Authority = domain;
                options.Audience = "https://myAuth0Audience.com";
            })
        .AddJwtBearer(MsaOpenId, options =>
            {
                options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters
                {
                    ValidateAudience = true,
                    ValidAudience = "00000000-0000-0000-0000-000000000000",

                    ValidateIssuer = true,
                    ValidIssuer = "https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0",

                    ValidateIssuerSigningKey = true,
                    RequireExpirationTime = true,
                    ValidateLifetime = true,
                    RequireSignedTokens = true,
                    ClockSkew = TimeSpan.FromMinutes(10),
                };
                options.MetadataAddress = "https://login.microsoftonline.com/9188040d-6c67-4c5b-b112-36a304b66dad/v2.0/.well-known/openid-configuration";
            }
        );

services.AddAuthorization(options =>
{
    options.DefaultPolicy = new AuthorizationPolicyBuilder()
        .RequireAuthenticatedUser()
        .AddAuthenticationSchemes( Auth0, MsaOpenId )
        .Build();

    var approvedPolicyBuilder =  new AuthorizationPolicyBuilder()
           .RequireAuthenticatedUser()
           .AddAuthenticationSchemes(Auth0, MsaOpenId)
           ;

    approvedPolicyBuilder.Requirements.Add(new HasApprovedRequirement(domain));

    options.AddPolicy("approved", approvedPolicyBuilder.Build());
});