. net Core 3.0 и OpenId Connect - Как настроить аутентификацию для проверки Azure сгенерированного не-JWT-токена доступа против UserInfo в WebAPI? - PullRequest
Новая
       76

. net Core 3.0 и OpenId Connect - Как настроить аутентификацию для проверки Azure сгенерированного не-JWT-токена доступа против UserInfo в WebAPI?

0 голосов
/ 05 февраля 2020

Итак, у нас есть SPA, называющий серию микросервисами, который находится за шлюзом API. Схема аутентификации - поток OpenId против Azure AD. Итак, это происходит следующим образом: SPA (клиент Publi c) получает код доступа, затем шлюз API (конфиденциальный клиент) вызывает службу токена для получения токена доступа; это то, что передается самим микросервисам. Таким образом, в итоге наши микросервисы получат только токен доступа не-JWT . Важно отметить, что этот токен НЕ является JWT. Для проверки мы вынуждены использовать конечную точку / openId / UserInfo в клиенте azure, чтобы проверить пользователя с токеном доступа.

Мы пытались использовать расширение AddOpenIdConnect при запуске, как описано [здесь] https://docs.microsoft.com/en-us/dotnet/architecture/microservices/secure-net-microservices-web-applications/ 

{
    //…
    // Configure the pipeline to use authentication
    app.UseAuthentication();
    //…
    app.UseMvc();
}

public void ConfigureServices(IServiceCollection services)
{
    var identityUrl = Configuration.GetValue<string>("IdentityUrl");
    var callBackUrl = Configuration.GetValue<string>("CallBackUrl");

    // Add Authentication services

    services.AddAuthentication(options =>
    {
        options.DefaultScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.DefaultChallengeScheme = OpenIdConnectDefaults.AuthenticationScheme;
    })
    .AddCookie()
    .AddOpenIdConnect(options =>
    {
        options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.Authority = identityUrl;
        options.SignedOutRedirectUri = callBackUrl;
        options.ClientSecret = "secret";
        options.SaveTokens = true;
        options.GetClaimsFromUserInfoEndpoint = true;
        options.RequireHttpsMetadata = false;
        options.Scope.Add("openid");
        options.Scope.Add("profile");
        options.Scope.Add("orders");
        options.Scope.Add("basket");
        options.Scope.Add("marketing");
        options.Scope.Add("locations");
        options.Scope.Add("webshoppingagg");
        options.Scope.Add("orders.signalrhub");
    });
}

Но это предполагает весь поток OpenId. Независимо от помещения токена Bearer в запрос, приложение перенаправляет на страницу входа в систему.

Итак, вопрос в том, есть ли для этого какая-либо конфигурация? Или мы должны полагаться на какой-то пользовательский обработчик? В таком случае, как пользователь может быть надлежащим образом аутентифицирован в контексте? Нам нужно получить доступ к HttpContext.User.Claims в самих контроллерах.

Любая подсказка будет принята с благодарностью!

1 Ответ

0 голосов
/ 05 февраля 2020

Могу ли я задать пару вопросов - частично для моего собственного понимания:

  • Почему маркер не является JWT - я не думаю, что ссылка, которую вы разместили, объясняет это?
  • Используете ли вы какую-либо форму обмена токенами от оригинала, выданного SPA?

У меня есть эквивалентное решение, которое работает, но я использую бесплатную учетную запись разработчика, так что, возможно, мой установка отличается:

Если Я понимаю, как воспроизвести ваши настройки - и грубое понимание различий в конфигурации - я могу помочь.

Использование конечной точки информации пользователя для проверки токенов не кажется правильным. Было бы хорошо, чтобы проверка токенов работала стандартным образом.

...