問題が発生している DNOA の実装があります。私が見たサンプルのコードは間違っていて動作せず、これを正しく動作させる方法がわかりません。
ここの DNOA グループで同様の質問をしましたが、これが実際に OAuth 一般に関連するより大きな質問であるかどうか疑問に思っています。Andrew は、これでうまくいくはずだと主張していますが、多くの人が同じ質問をしているのを見て、本当の解決策はありません。
ExchangeUserCredentialForToken DNOA を使用すると、ユーザー名とパスワードの資格情報が承認サーバーに送信されます。内部では、これは client_id および client_secret プロパティをワイプするように見える NetworkCredential クラスを使用します (これらは明らかに基本認証 HTTP ヘッダーに移動され、次に HttpWebRequest によってワイプされます。
DNOA サンプルでは、ユーザーとこのクライアントに対して有効な承認がシステムに保持されていることをコードがチェックするのを見てきました。
クライアント識別子がないと、有効な承認を確認することはできません。これは、要求されたスコープが、ユーザーがクライアントにアクセスを許可したかどうかを確認できないためです。
私の理解が間違っているか、私が見たサンプルが間違っているか、DNOA に問題があるとしか思えません。
次を使用して、access_token を手動で逆シリアル化しようとしました。
var token = accessTokenAnalyser.DeserializeAccessToken(new Dummy(), authHeader.Replace("Bearer ", ""));
ただし、アクセス トークンの clientidentifier も null でした。
DNOA グループのスレッドを読み取ると、クライアント識別子は CreateAccessToken メソッドでも使用できるはずですが、決してそうではなく、常に null であることがわかります。
サンプルの別のシナリオでは、承認サーバーが TryAuthorizeResourceOwnerCredentialGrant に承認を自動的に追加することを示していますが、clientidentifier が常に null であるため、これも不可能です。
クライアント識別子の使用に関する私の仮定が完全に間違っているか、承認サーバーでクライアント識別子をリクエストに入れるための解決策について、誰でもアドバイスできますか。
また、この承認プロセス中にクライアントを認識できない場合、クライアント スコープのチェックを強制することもできません。
NetworkCredential クラスを取得して、リクエストで client_id を null にせずに渡す方法を知っている人はいますか?