なぜredirect URLは完全に一致する必要がありますか？適切なセキュリティのために十分なドメインレベルで一致しないでしょうか？Azure AD B2CでリダイレクトURLが完全修飾されているのはなぜですか？
何百ものパスがあったらどうしますか？
例のURL：
...
上記の4つのリダイレクトURLをB2Cアプリ設定に入力する必要があります。
これは実際にはRFC 6819「OAuth 2.0の脅威モデルとセキュリティに関する考慮事項」のセクション4.1.5,4.2.4および5.2.3.5で説明しています。
4.1.5。脅威：クライアント上のオープンリダイレクタ
オープンリダイレクタは、自動的にパラメータを使用するエンドポイントです。 ユーザエージェントは、パラメータ値 で指定された場所に自動的にリダイレクトされます。認可サーバーがクライアント にリダイレクトURIの一部のみを登録できる場合、攻撃者はクライアントによって開かれたリダイレクター を使用してリダイレクトURIを構成し、 が認可サーバーの検証に合格しますが、 認可コード攻撃者のコントロール の下にあるエンドポイントにトークンにアクセスします。
影響：攻撃者は、認証「コード」またはアクセストークンにアクセスできます。
対策：
oはURIをリダイレクトフル（Section 5.2.3.5）を登録するためにクライアントが必要「これは厳しすぎると目的別の解決策かもしれ例について
Section 5.2.3.5会談をしばしば
。また、stateパラメータを使用して、Chrisが提案したように確定的にリダイレクトすることもできます。
ドメインmyawesomesite.comを所有していて、そのドメインのリダイレクトURLを許可するオープンリダイレクタがある場合、どうすれば攻撃者の猿とリダイレクトURI？それでも私のドメインにリダイレクトする必要があります。 – spottedmahn
一般的なケースは、redirect_urlがいくつかのクエリパラメータを受け入れ、攻撃者がそのサイトにリダイレクトする可能性がある場合です。脅威モデルは、ユーザーエージェントが「検証なしで」リダイレクトされることを前提としています。あなたが示唆しているのは何らかの種類の制約や検証です。 Azure ADは、ほとんどの場合に有効な手法とのバランスを取ろうとしますが、ワイルドカードとクエリパラメータは依然として制限されています。 （これらの脆弱性は今日もなお複雑なアプリケーションで起こっていることに注意してください：https://www.google.com/search?q="open+redirect"+vulnerability&tbm=nws） –
私の応答を編集していただきありがとうございます。私は昨晩モバイルページしか持っていなかったが、これは完全なエディタを持っていないようだ。 –
これは、2つのリダイレクトURLを含むように、すべての認証要求のための一般的な（かつ簡単な）です：
https://www.myawesomesite.com/oidc-signinです。https://www.myawesomesite.com/games/fungame/pointsです。認証ハンドラ（the ASP.NET Core authentication middlewareなど）は、これらのリダイレクトURLを管理します。
たとえば、認証ハンドラが認証要求を作成すると、「状態」要求パラメータに現在保護されているURL（たとえばhttps://www.myawesomesite.com/games/fungame/points）がエンコードされます。
このURLが改ざんされないようにするには、暗号化または署名を使用して「状態」パラメータを保護する必要があります。
認証ハンドラが認証応答を処理すると、応答が成功したとみなしてIDクッキーを作成し、エンドユーザをhttps://www.myawesomesite.com/oidc-signinから "state"応答パラメータの元の保護されたURLにリダイレクトします。
y私たちのすばらしいアプリは、同じエンドポイントですべての認証レスポンスを処理します（例：/oidc-signin）？ –
いいえ、100のユニークなパスがあり、99個が認証されているとします。ユーザーは99のパスのいずれかにブックマークを付けることができます。 – spottedmahn
@ChrisPadgett認証されたページにアクセスした場合、B2Cにリダイレクトしてそのページに戻る必要があります。 – spottedmahn