ここにある MVC 用の OAuth 2.0 を使用しています。 -implementation.aspx
これを扱ったことのある人にとっては、RequestToken について混乱しています。5 分で期限切れになるリクエスト トークンを取得できるコントローラーが実装されており、そのトークンを戻して AccessToken を取得します。しかし、リクエスト トークンの有効性をチェックすることはありません。必要なアクセス トークンを渡すことができるようです。ここでの RequestToken のアイデアは何ですか?その 5 分間、そのトークンを保存、参照、および削除する独自の方法を作成することになっていますか?
ありがとう、アンディ
これは、OAuth がアプリケーション ID、アプリケーション シークレット キー、およびアプリケーションの有効なドメインと連携してどのように機能するかについてのすべてです。大まかな流れはこちら
アプリケーションは、アプリケーション ID とシークレットをコールバック (リターン URL) と共に使用して、OAuth プロバイダーにリクエストを送信します。
OAuth プロバイダーはリクエストを取得し、アプリケーション ID とシークレットをチェックして、コールバック URL がアプリケーション用に指定したドメインからのものであることを検証します。
2a. コールバック URL が指定したドメインからのものでない場合、リクエストはエラーで拒否されます。
2b コールバック URL がドメインからのものである場合、一時的なリクエスト キーがサーバーに返されます。
リクエスト キーを受け取ったら、それを OAuth プロバイダーに送り返し、ユーザーの実際のアクセス トークンを取得します。
ここで、リクエスト キーのステップが設けられている理由について説明します。これは、「悪い人」がアプリケーション ID を使用して他のユーザーを誤って認証しようとするのを防ぎ、保護するためです。リクエスト トークン (承認済みのコールバック URL) を送信することで、OAuth プロバイダーは、リクエストが実際にサーバーから送信されたことを確信できます。
リクエスト トークンの代わりに任意の文字列を送り返すことができますが、そのリクエスト トークンは既知のアプリケーションからの既存の認証リクエストに対応していないため、OAuth プロバイダーからすぐにエラーが返されます。
最後に、「リクエストトークンを検証する」とはどういう意味ですか? トークンを生成しなかったのではなく、リクエスト トークンを生成するためのアルゴリズムを理解していない可能性があります。それを考えると、これをどのように検証するのかわかりません。最初のステップの検証に不安がある場合は、Facebook OAuth プロセスをご覧ください。そこでは、リターン URL の一部として (クエリ文字列パラメーターとして) 要求キーを送信することをお勧めします。そのリクエストキーはアプリケーションに返され、これを検証として使用できます。実際、これはあなたが行ったリクエストに対するレスポンスです。そのリクエストキーをどのように保存して追跡するかはあなた次第です（セッション、データベース）。PHP サンプルでは、'state' 変数を使用して一意/任意の文字列を追跡します: Facebook OAuth サーバー側ログインの例 (PHP)