OWIN OpenIdConnect Middleware IDX10311 nonce не может быть проверен

У меня есть приложение, использующее промежуточное ПО OWIN для OpenIdConnect. Файл startup.cs использует стандартную реализацию app.UseOpenIdConnectAuthentication. Файл cookie установлен в браузере, но с ошибкой:

IDX10311: RequireNonce является "истинным" (по умолчанию), но validationContext.Nonce имеет значение null. Функция nonce не может быть проверена. Если вам не нужно проверять nonce, установите OpenIdConnectProtocolValidator.RequireNonce на "false".

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

С fiddler:

SecurityTokenВведенное уведомление в OpenIdConnect выполняется дважды.
После второго прохода через ошибку IDX10311 вызывается
Браузер содержит действительный файл cookie, вернувшись на страницу, я могу просмотреть действительные данные User.Identity.

Работа без скрипача:

SecurityTokenValidated выполняется один раз в OpenIdConnect
Ошибка сброшена, продолжается загрузка действия контроллера для перенаправления после аутентификации Uri
Cookie также действительна, а данные User.Identity верны.

Идеи? Я могу обойти это без запуска скрипача, но при отладке было бы неплохо запустить скрипач, чтобы проверить трафик.

Ответ 1

Я знаю, что это было какое-то время на этом. Моя конкретная проблема была связана с ошибкой IDX10311, связанной с аутентификацией с помощью IdentityServer во время работы Fiddler (прокси-сервер инспектора трафика). Я добавил специальное промежуточное ПО owin, чтобы поймать и поглотить IDX13011 в случае, когда имя хоста содержало "localhost". Игнорирование этого исключения позволило нам использовать сайт с fiddler в качестве обходного пути. Я думаю, что это вызывает перерывы в процессе аутентификации, хотя там, где мы должны нажать Enter в адресной строке браузера на обратных вызовах, чтобы это возобновилось, но это влияет только на разработку.

Здесь метод invoke мы использовали в промежуточном программном обеспечении для поглощения ошибки. Должен отметить, что мы иногда видели и эту ошибку в производстве. нет объяснения причины, но у меня есть ощущение, что это связано с пользователями в браузерах IE.

public override async Task Invoke(IOwinContext context) {
        try {
            await Next.Invoke(context);
        } catch (Exception ex) {
            _errorHandling = new ErrorHandling();
            if (ex.Message.Contains("IDX10803")) {
                //do something here to alert your IT staff to a possible IdSvr outage
                context.Response.Redirect("/Error/IdSvrDown?message=" + ex.Message);
            } else if(ex.Message.Contains("IDX10311") && context.Request.Host.Value.Contains("localhost")) {
                //absorb exception and allow middleware to continue
            } else {
                context.Response.Redirect("/Error/OwinMiddlewareError?exMsg=" + ex.Message + "&owinContextName=" + lastMiddlewareTypeName);
            }
        }
    }

Ответ 2

Может быть, это причина?

Здравствуйте, я думаю, что нашел основную причину этой проблемы.

Я подытоживаю свои открытия:

Проблема в файле cookie OpenIdConnect.nonce.OpenIdConnect
Этот файл cookie устанавливается из приложения (пусть он называется "ID Client"), как только промежуточное ПО OpenID запускает сеанс аутентификации.
Файл cookie должен быть отправлен обратно из браузера на "ID Client", как только аутентификация будет завершена. Я предполагаю, что этот файл cookie необходим для двойной проверки с точки зрения клиента ID (т.е. Действительно ли я запустил поток авторизации OpenID Connect?)
Много путаницы во мне было вызвано термином "Nonce", используемым как в этом файле cookie, так и в потоке OpenID Connect с сервера ID.
Исключение, в моем случае, было вызвано отсутствующим файлом cookie (не одноразовым номером сервера ID), просто потому, что браузер не отправил его обратно "клиенту идентификатора"

Таким образом, основной корень, в моем случае, был следующим: файл cookie OpenIdConnect.nonce.OpenIdConnect не был отправлен обратно клиенту идентификатора браузером. В некоторых случаях (например, Chrome, Firefox и Edge) cookie отправлялся правильно, а в других (IE11, Safari) - нет.

После долгих исследований я обнаружил, что проблема заключается в политике ограничения Cookie, определенной в браузере. В моем случае "идентификатор клиента" встроен в <iframe>. Это приводит к тому, что "ID Client" будет рассматриваться как "сторонний клиент", поскольку пользователь не переходил по этому URL-адресу непосредственно в главном окне. Поскольку это сторонние, для некоторых браузеров куки файлы должны быть заблокированы. Действительно, тот же эффект можно получить в Chrome, установив "Блокировать сторонние куки".

Итак, я должен сделать вывод, что:

a) Если iframe является обязательным (как в моем случае, потому что "ID-клиенты" - это приложения, которые должны запускаться внутри графического содержимого нашего основного приложения платформы), я думаю, что единственное решение - перехватить ошибку и обработать ее с помощью страница с просьбой включить сторонние файлы cookie.

б) Если iframe не обязателен, достаточно открыть "ID Client" в новом окне.

Надеюсь, это кому-нибудь поможет, потому что я сошел с ума!

Marco

Ответ 3

У меня была та же проблема, но при возврате Microsoft.Owin.Security.OpenIdConnect в версию 3.0.1 была решена проблема

Ответ 4

Я знаю его старый пост, но у меня была эта проблема, и ничто не работало для меня, после того как я потерял сознание за решением, чтобы заставить мое корпоративное приложение работать, я в конечном итоге исправил его, установив многозадачный вариант на yes в azure (в Azure выберите: регистрация приложений > настройки > свойства, настройте multi-tenanted на yes и нажмите save).

надеюсь, что это поможет кому-то, не видел, чтобы никто не упоминал об этом.

Ответ 5

Для меня изменение URL ответа в Azure Active Directory работает.

Это происходит, когда вы включаете SSL, потому что он меняет только URL-адрес входа на URL-адрес HTTPS, а URL-адрес ответа остается тем же URL-адресом HTTP.

Когда вы пытаетесь получить доступ к своему приложению с помощью URL-адреса https, он устанавливает в вашем браузере файл cookie с уникальным номером (nonce) и обращается к Azure AD для проверки подлинности. После аутентификации браузер должен предоставить доступ к этому cookie. Но поскольку URL-адрес и URL-адрес ответа различаются, браузер не распознает ваше приложение и не предоставляет доступ к этому cookie, и, следовательно, приложение выдает эту ошибку.

Ответ 6

Я заметил эту ошибку при запуске IIS Express в фоновом режиме, когда я перешел на хостинг в полном IIS. Когда я отключил IIS Express, моя ошибка исчезла.

Ответ 7

Правило перезаписи файлов cookie в файле web.config, чтобы гарантировать, что файлы cookie того же сайта дали это загадочное исключение. Отключение этого правила решило это.

Ответ 8

Временное решение, которое работало для меня для приложения, защищенного через Azure Active Directory, состояло в том, чтобы выйти из системы (перейдя на страницу sites/Account/SignOut), а затем я смог вернуться на домашнюю страницу и войти в систему в порядке. Надеюсь, это кому-нибудь поможет.