Ошибка обратного вызова EasyAuth веб-приложения Azure
У меня есть приложение ASP.NET MVC, работающее как Azure Web App.
Я использую предварительную аутентификацию /EasyAuth, и для 5 слотов развертывания она работает нормально. У каждого из них есть собственная регистрация приложения Azure AD.
Но рабочий сайт (не слот развертывания, корень приложения) выдает ошибку при входе в /.auth/login/aad/callback дорожка: 
Я сравнил манифест приложения Azure AD с работающим, и единственное отличие заключается в именах, описании и URL-адресах - как и ожидалось.
Использование Kudu для просмотра ошибки, кажется, происходит из EasyAuthModule: 
1 ответ
Итак, в основном это была проблема с используемой регистрацией приложений, которые были созданы из другого слота развертывания.
Даже если Authentication / Authroization для веб-приложения, настроенного как Express, была выбрана правильная регистрация приложения - оказалось, что клиентский секрет не был передан из регистрации приложения в веб-приложение (в моем случае он имел неправильный ключ): 
Чтобы исправить это, вы можете переключиться на расширенный, как показано выше, открыть соответствующую регистрацию приложения и создать новый ключ: 
Ключ не отображается до тех пор, пока вы не сохраните его, и отображается только один раз. Скопируйте его и вставьте в поле ввода Client Secret веб-приложения.
После сохранения всех блейдов можно вернуться к экспресс-аутентификации. настройки и ключ останется.
Поскольку я не могу комментировать, я добавлю свой случай в качестве ответа более подробно, чем я хотел бы в комментарии.
У меня были точно такие же сообщения об ошибках от Easyauth в приложении ASP.NET MVC, работающем как веб-приложение службы приложений Azure.
Первоначальное сообщение об ошибке было просто "Невозможно отобразить страницу, потому что произошла внутренняя ошибка сервера". А через FTP и / или Visual Studio Server Explorer и / или Cloud Explorer я мог проверить страницу реальной ошибки после установки подробных сообщений об ошибках из журналов службы приложений. Эти ошибки были такими же, как и в случае с MartinHN при использовании Kudu.
Таким образом, в более подробном описании ошибки преимущественно показанная ошибка 500,74 изначально указала мне неверное направление (MFA). Но запрос URL (.auth/login/aad/callback), в котором сообщение об ошибке указывало, что произошла внутренняя ошибка сервера, привел меня к этому вопросу SO.
В моем случае, хотя у меня уже была выбрана расширенная конфигурация в проверке подлинности Active Directory служб приложений. И секретный ключ клиента был не просто неправильным. Оказалось, что срок действия секрета клиента истек. Но для меня это было неочевидно, поскольку у меня нет доступа к AAD. Мне пришлось связаться с отдельной командой AD, чтобы проверить секреты.
Таким образом, просроченный секрет клиента (ключи) также может вызвать ту же ошибку.