Не удается пройти аутентификацию с помощью JWT в клиенте MVC

Я установил следующую аутентификацию в своем клиенте MVC.

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
services.AddAuthentication(_ =>
{
  //_.DefaultScheme = "Cookies";
  //_.DefaultChallengeScheme = "oidc";
  _.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
})
  .AddCookie("Cokies")
  .AddFacebook()
  .AddGoogle()
  .AddJwtBearer()
  .AddOpenIdConnect("oidc", _ => { });

Поскольку по умолчанию используется JWT, я полагаю, что другие (Cookie, Facebook, Google и OpenIdConnect) просто игнорируются, если декоратор авторизации вызывается без параметров.

Однако я просто получаю 401 Unauthorized без дополнительной информации. Например, если я закомментирую оператор схемы по умолчанию для JWT и активирую файл cookie следующим образом:

{
  _.DefaultScheme = "Cookies";
  _.DefaultChallengeScheme = "oidc";
  //_.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
}...

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

Чего мне не хватает в моем клиенте MVC, чтобы он правильно аутентифицировался? Или проблема в моей конфигурации IDS4?

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

Укороченная версия, по-прежнему вызывающая ту же проблему, выглядит так.

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear();
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
  .AddJwtBearer(_ =>
  {
    _.Authority = "https://localhost:44300";
    _.Audience = "http://localhost:5001";
  });

Мой IDS4 работает на порту 44300 (проверено с помощью .well-known), а API — на порту 5001.


person Konrad Viltersten    schedule 30.12.2018    source источник
comment
Можете ли вы поделиться токеном JWT, созданным во время аутентификации? Также есть ли причина, по которой вы не используете nuget-пакет idsrv4 для проверки токена?   -  person Vidmantas Blazevicius    schedule 31.12.2018
comment
@VidmantasBlazevicius Спасибо за ответ, приятель. Что касается токена - как я могу получить его в открытом виде. Я перехожу к конечной точке, украшенной [Authorize], и затем происходит черная магия IDS. Что мне не хватает? Что касается проверки, у меня установлен пакет IDS4.AccessTokenValidation, но я могу запутаться в его использовании. Он должен быть установлен в проекте IdServer, а не в проекте MvcClientApp, верно? (Я внимательно изучил руководство по IDS, и оно хорошее, но начинает немного устаревать и становится немного нервным между темами. Так что - это моя некомпетентность и замешательство.   -  person Konrad Viltersten    schedule 31.12.2018
comment
Если это реальный код, то .AddCookie("Cokies") может быть одной из проблем. Что касается пакета NuGet, API — это проект, для которого требуется пакет: github.com/IdentityServer/IdentityServer4.Samples/blob/master/   -  person Ruard van Elburg    schedule 31.12.2018
comment
@RuardvanElburg Я тоже так думал, поэтому удалил все это (об этом упоминается в последней части вопроса). Тем не менее остается та же проблема. Я почти уверен, что это я делаю что-то глупое и не вижу, что. Или, скорее, я пропускаю добавление чего-то нужного, а не добавляю что-то ошибочное. Что касается ссылки - я просмотрел их, но, как я уже сказал, большинство примеров немного устарели (например, теперь мы должны использовать методы расширения для HttpClient вместо специализированных классов для получения URL-адресов и т. д.). Я хочу ориентироваться на Core 2.2/IDS4, и мне еще предстоит найти хороший пример/блог по этому поводу.   -  person Konrad Viltersten    schedule 31.12.2018
comment
@VidmantasBlazevicius Меня смутило отсутствие /connect/accesstokenvalidation и увидел сообщение о том, что его больше нельзя использовать.   -  person Konrad Viltersten    schedule 31.12.2018
comment
Вы можете захватить токен, проверив сетевой трафик, например, в инструментах chrome dev. Что касается пакета, то его необходимо установить на стороне клиента.   -  person Vidmantas Blazevicius    schedule 31.12.2018
comment
@VidmantasBlazevicius О, хорошо - тогда я сначала установил его правильно. Я снова добавил пакет в клиент MVC и удалил его из проекта ID-сервера. Теперь, изучив сеть, я обнаружил, что получаю кучу изображений (PNG и SVG), но ничего похожего на токен... Что за глупость я мог пропустить? Я чувствую себя ужасно потерянным, чтобы устранить эту проблему...   -  person Konrad Viltersten    schedule 31.12.2018
comment
@VidmantasBlazevicius Я только что кое-что понял. В определении клиента (которое сделано в проекте IDS4) я установил точку URL-адреса перенаправления на страницу в приложении MVC. Это проблема? Не должно быть, верно? Или требуется, чтобы страница входа обслуживалась из проекта Identity Server?   -  person Konrad Viltersten    schedule 31.12.2018
comment
URI перенаправления обычно выглядит как http://localhost:5000/signin-oidc по умолчанию для ASP.NET Core MVC. Вы должны иметь возможность проверять трафик при переходе на любую страницу с атрибутом [Authorize] на контроллере. Трафик должен начинаться с обращения к вашему серверу идентификации, затем к внешнему провайдеру (если вы его используете), затем обратно к серверу идентификации и, наконец, обратному вызову к вашему клиенту MVC. Обратный вызов — это место, где токен обычно находится в теле ответа.   -  person Vidmantas Blazevicius    schedule 31.12.2018
comment
@VidmantasBlazevicius Я боюсь, что моя проблема глубже, чем я могу объяснить. Возможно, это потому, что я использую HTTPS или что-то в этом роде. Я нажимаю на конечную точку с помощью [Authorize], но на вкладке «Сеть» я ничего не вижу о каких-либо переходах... Что касается RedirectURL, он должен указывать на страницу входа, верно? Поэтому мне придется активировать статические файлы в проекте ID-сервера и создать страницу входа, которая будет стилистически похожа на мое приложение MVC. Это правильно?   -  person Konrad Viltersten    schedule 31.12.2018
comment
RedirectUrl обычно является страницей входа, а не страницей входа. Если вы используете промежуточное ПО ASP.NET Core .UseAuthentication(), оно должно быть http://yourdomain/signin-oidc. Также можно попробовать без https?   -  person Vidmantas Blazevicius    schedule 31.12.2018
comment
@VidmantasBlazevicius Я удалил HTTPS и теперь использую только небезопасные соединения. Та же проблема остается. Что касается ссылки, которую вы предложили - какое из приложений должно быть правильным? Я запускаю поставщика идентификаторов, API и клиента MVC на localhost просто на разных портах (конечно, в производстве это будут разные серверы). На каком из серверов должен находиться signin-oidc?   -  person Konrad Viltersten    schedule 07.01.2019
comment
Страница входа — это встроенная конечная точка для обработки обратного вызова от поставщика oidc в клиенте MVC, которую можно создать, просто запустив новый проект asp.net core mvc. Вы устанавливаете это как uri обратного вызова в настройке клиента на сервере идентификации. Где размещается каждый компонент — на одном или разных серверах — здесь нет никакой разницы, поскольку этот протокол основан на http.   -  person Vidmantas Blazevicius    schedule 08.01.2019
comment
@VidmantasBlazevicius Извините за задержку. Я был госпитализирован. Теперь я вернулся. Меня немного смущают точные детали того, на что должен указывать RedirectUrl. Вы говорите (а) настроить определение клиента в настройках IDS4 и установить RedirectUri={localhost:5002/ домой/логин}? Или вы каким-то образом имеете в виду (b) конфигурацию настройки клиента MVC services.AddAuthentication(...)...? Или, может быть (с) что-то еще?   -  person Konrad Viltersten    schedule 13.01.2019
comment
Ссылаясь на оба на самом деле. В настройке клиента idsrv4 URL-адрес перенаправления должен быть yoursiteurl/signin-oidc . Если вам нужен работающий пример, просто посмотрите краткие руководства по idsrv4. По сути, это конечная точка обработчика во встроенном промежуточном программном обеспечении аутентификации aspnetcore для входа пользователя при обратном вызове от поставщика удостоверений.   -  person Vidmantas Blazevicius    schedule 13.01.2019
comment
@VidmantasBlazevicius Возможно, это меня и смутило. Должен ли я на самом деле реализовывать конечную точку (или статический файл), достигаемую по адресу localhost:5002/signin-oidc (порт 5002 — это мое клиентское приложение MVC)? Или это автоматически обрабатывается моим вызовом services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)? Я нахожу документы на официальном сайте немного расплывчатыми.   -  person Konrad Viltersten    schedule 13.01.2019
comment
@KonradViltersten Эй, проверьте этот ответ, который я опубликовал, в нем в основном подробно описывается, что вам нужно настроить на вашем клиенте MVC и IDS4) stackoverflow.com /questions/54173177/ Чтобы ответить на ваш вопрос, да, конечные точки обработчика встроены в промежуточное ПО службы аутентификации.   -  person Vidmantas Blazevicius    schedule 14.01.2019