OWIN OpenIdConnectミドルウェアIDX10311ナンスを検証できません
OpenIdConnect用のOWINミドルウェアを使用するアプリケーションがあります。 startup.csファイルは、app.UseOpenIdConnectAuthenticationの標準実装を使用します。 Cookieはブラウザに設定されますが、次のエラーが発生します。
IDX10311：RequireNonceは 'true'（デフォルト）ですが、validationContext.Nonceはnullです。ナンスは検証できません。ナンスを確認する必要がない場合は、OpenIdConnectProtocolValidator.RequireNonceを「false」に設定します。
ほとんどのデバッグプロジェクトで行うようにフィドラーを実行すると、この動作が発生することがわかりました。エラーが返されますが、サイトに戻るとすべてが機能し、ユーザーが認証されています。フィドラーを実行しているときに誰かがこの動作を見ましたか？
フィドラーの場合：
- OpenIdConnectのSecurityTokenValidated通知は2回実行されます。
- IDX10311エラーの2回目のパスがスローされた後
- ブラウザには有効なCookieが含まれており、有効なUser.Identityデータを表示できるページに戻ります。
フィドラーなしで実行する：
- SecurityTokenValidatedはOpenIdConnectで1回実行されます
- エラーはスローされず、認証後リダイレクトUriのコントローラーアクションのロードに進みます
- Cookieも有効であり、User.Identityデータが正しい。
アイデア？フィドラーを実行せずに回避できますが、デバッグ時には、フィドラーを実行してトラフィックを検査することもできます。
これが原因なのでしょうか？
こんにちは、この問題の根本原因を見つけたと思います。
私の発見を要約しています：
問題はOpenIdConnect.nonce.OpenIdConnect Cookieにあります
このCookieは、OpenIDミドルウェアが認証セッションを開始するとすぐに、アプリから設定されます（この「IDクライアント」と呼びます）。
Cookieは、認証が完了するとすぐにブラウザから「ID Client」に送り返される必要があります。私の仮定は、IDクライアントの観点から二重チェックを行うためにこのCookieが必要であるということです（つまり、実際にOpenID Connect認証フローを開始しましたか？）
私の多くの混乱は、このCookieとIDサーバーからのOpenID Connectフローの両方で使用される「Nonce」という用語によって引き起こされました。
私の場合、例外は、ブラウザによって「IDクライアント」に返送されなかったという理由だけで、Cookieの欠落（IDサーバーのnonceではない）が原因でした。
私の場合、メインルートはこれでした。OpenIdConnect.nonce.OpenIdConnectCookieは、ブラウザによってIDクライアントに返されませんでした。場合によっては（つまり、Chrome、Firefox、Edge）Cookieが正しく送信されましたが、他の場合（IE11、Safari）ではそうではありませんでした。
多くの調査の結果、問題はブラウザで定義されたCookie制限ポリシーにあることがわかりました。私の場合、「IDクライアント」は<iframe>。これにより、ユーザーはメインウィンドウでそのURLに直接移動しなかったため、「IDクライアント」は「サードパーティクライアント」と見なされます。これはサードパーティであるため、一部のブラウザでは、Cookieをブロックする必要があります。実際、「サードパーティのCookieをブロックする」を設定すると、Chromeで同じ効果が得られる場合があります。
だから、私はそれを結論付ける必要があります：
a）iframeが必須の場合（私の場合、「IDクライアント」はメインプラットフォームアプリのグラフィックコンテンツ内で実行する必要があるアプリであるため）、唯一の解決策はエラーをインターセプトし、サードパーティのCookieを有効にするようユーザーに求めるページ。
b）iframeが必須ではない場合、新しいウィンドウで「IDクライアント」を開くだけで十分です。
私が夢中になったので、これが誰かを助けることを願っています！
マルコ
同じ問題が発生しましたが、Microsoft.Owin.Security.OpenIdConnectバージョン3.0.1で問題が解決しました
私はその古い投稿を知っていますが、この問題があり、何も機能していませんでした。エンタープライズアプリケーションを動作させるソリューションの背後に頭を失った後、Azureでマルチテナントオプションをyesに設定することで修正します（Azureで選択：アプリ登録>設定>プロパティ、マルチテナントをyesに設定し、保存をクリックします）。
それが誰かを助けることを願って、誰もそれを言及するのを見ることができなかった。
私にとって、Azure Active Directoryで返信URLを変更することはできます。
SSLを有効にすると、返信URLは同じHTTP URLのままで、サインオンURLのみがHTTPS URLに変更されるため、これが発生します。
Https URLを使用してアプリにアクセスしようとすると、ブラウザーで一意の番号（nonce）を使用してCookieが設定され、認証のためにAzure ADにアクセスします。認証後、ブラウザはそのCookieへのアクセスを許可する必要があります。ただし、サインオンURLと応答URLは異なるため、ブラウザーはアプリを認識せず、そのCookieへのアクセスを許可しないため、アプリケーションはこのエラーをスローします。
Azure Active Directoryを介してセキュリティで保護されたアプリの一時的な解決策は、サインアウト（sites/Account/SignOutページに移動）することでした。その後、ホームページに戻ってサインインできました。これが誰かを助けることを願っています。
完全なIISでホスティングに切り替えたときに、バックグラウンドでIIS Expressを実行しているときにこのエラーに気付きました。IIS Expressを無効にすると、 。
同じサイトCookieがこの不可解な例外を確実に発生させるために、web.configのCookie書き換えルール。そのルールを無効にすることで解決しました。