#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 не нужно было знать или заботиться о том, какой тип токена доступа он получает.
Самоанализ будет происходить только при первом получении токена доступа. Последующие запросы с тем же токеном затем используют кэшированные утверждения.
Ресурсы