Могу ли я создать сервер идентификации 4 ASP.NET Основной API, использующий 2 разных промежуточных программного обеспечения для проверки подлинности токенов?

#asp.net-core #jwt #identityserver4 #access-token #middleware

#asp.net-core #jwt #identityserver4 #токен доступа #промежуточное программное обеспечение

Вопрос:

Я пытаюсь выяснить, возможно ли написать ASP.NET Основной API, который использует токен сервера идентификации, используя либо ссылочные токены, либо токены JWT, на основе того, что я настроил для использования на своем сервере идентификации. Внутренняя конфигурация для IS4 довольно проста, я просто не уверен, что смогу настроить 2 разных промежуточных ПО для токенов, и моя служба будет с этим согласна и будет знать, что делать.

Итак, идея в том:

  • Если мой API получает jwtToken, он пытается использовать промежуточное программное обеспечение jwt для авторизации обратно на сервер идентификации.
  • Если мой API получает ссылочный токен, он пытается использовать промежуточное программное обеспечение introspection для авторизации обратно на сервер идентификации.

Очевидно, что если указан неправильный тип токена для всего, что настроено в службе IS4, произойдет сбой.

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

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

Ответ №1:

Согласно документу Identity Server 4 Protecting APIS, мы можем видеть, что он поддерживает использование как JWT, так и ссылочных токенов в asp.net ядро.

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

 services.AddAuthentication("token")

    // JWT tokens
    .AddJwtBearer("token", options =>
    {
        options.Authority = Constants.Authority;
        options.Audience = "resource1";

        options.TokenValidationParameters.ValidTypes = new[] { "at jwt" };

        // if token does not contain a dot, it is a reference token
        options.ForwardDefaultSelector = Selector.ForwardReferenceToken("introspection");
    })

    // reference tokens
    .AddOAuth2Introspection("introspection", options =>
    {
        options.Authority = Constants.Authority;

        options.ClientId = "resource1";
        options.ClientSecret = "secret";
    });
  

Ответ №2:

Поддержка как JWT, так и ссылочных токенов

В дополнение к сообщению @Zhi Lv вам может потребоваться добавить политику авторизации, схемы аутентификации, позволяющие проверять JWT и ссылочные токены.

Вот образец шаблона кода, в котором соответствующим образом заменяются имя api, секрет api и аудитория.

     public void ConfigureServices(IServiceCollection services)
    {
        services.AddControllers();

        services.AddAuthentication(IdentityServerAuthenticationDefaults.AuthenticationScheme)
            .AddJwtBearer(Options =>
            {
                Options.Authority = "https://identity.domain.com/identity/";
                Options.Audience = "resource1"; //your api baseurl e.g if you want userinfo_endpoint  specify https://identity.domain.com/identity/connect/userinfo

                Options.TokenValidationParameters.ValidTypes = new[] { "at jwt" };
            })
            .AddIdentityServerAuthentication(options =>
            {
                options.Authority = "https://identity.domain.com/identity/";
                options.ApiName = "api name / scope";
                options.ApiSecret = "api secret / scope secret";
            });

        services.AddAuthorization(options =>
        {
            options.AddPolicy("tokens", x =>
            {
                x.AddAuthenticationSchemes("jwt", "introspection");
                x.RequireAuthenticatedUser();
            });
        });
    }
  

Ответ №3:

Способ, которым я бы это сделал, — использовать самоанализ и кэширование утверждений в обоих случаях, чтобы API не нужно было знать или заботиться о том, какой тип токена доступа он получает.

Самоанализ будет происходить только при первом получении токена доступа. Последующие запросы с тем же токеном затем используют кэшированные утверждения.

Ресурсы