Facebookからaccess_tokenを取得するには、を送信する必要がありますapp_id。これcodeは、承認リクエスト後に受信したものと、アプリのを送信する必要がありますsecret_key。
なぜ秘密鍵を送信するのですか？これは明らかに安全ではないようです。これはOAuth2.0仕様の要件ですか？
app_id関連する質問として、リクエストがすでに署名されているのに、なぜ送信する必要があるのconsumer_keyですか？
私は動作するアプリを持っています、私はこれらの要件を理解していません。
これは、OAuth 2.0 仕様のセクション 4.1.3の要件です。
クライアントの種類が機密であるか、クライアント資格情報が発行された (または他の認証要件が割り当てられた) 場合、クライアントは、セクション 3.2.1 で説明されているように、承認サーバーで認証する必要があります。
また、セクション 3.2.1はセクション 2.3を参照しています。具体的には、セクション 2.3.1は次のように述べています。
または、認可サーバーは、次のパラメーターを使用して、リクエスト本文にクライアント資格情報を含めることを許可する場合があります。
クライアントID
REQUIRED. The client identifier issued to the client during
the registration process described by Section 2.2.
client_secret
REQUIRED. The client secret. The client MAY omit the
parameter if the client secret is an empty string.
OAuth 2.0 が提供する方法は他にもありますが、このアプローチを選択することで、Facebook は十分に仕様の範囲内に収まります。Facebookがこのアプローチを選択した理由は、おそらく Facebook だけが答えられるでしょう。
Oauth2 の要件であることに加えて、このステップで client_secret を使用して、あなたが実際に主張する人物であることを確認する必要があります。
それはすべて、プロセスがそのようなものである理由に要約されます...
最初のリクエストから返される「コード」は、セキュリティの観点から見ると非常に弱いものです。SSL で保護されていないランディング ページに移動することがよくあるリダイレクト リンクで、あなたに戻る途中でハイジャックされる可能性があります。サイト全体で 100% HTTPS を使用している場合でも、すべてが完全に安全というわけではありません。Web サーバーのアクセス ログ内に記録されるリクエスト URL を調べることで、誰かがコードを見つけることができます。
バッキンガム宮殿のこちら側でサーバーへのアクセスを制御する最も厳格なセキュリティ環境を持っていたとしても、テック ロデオに数年以上乗っていれば、ある時点で誰かがあなたのログをより低い場所に「アーカイブ」しようとしていることを知っています。 -理想よりも安全です。おそらく彼らがスターバックスに置き忘れたUSBキーに...
サーバー側の API フローを使用している場合、これを回避するために避けることはできません。クライアント ブラウザ内で実行されている Javascript とは異なり、ハッシュの後に一時コードを追加してログに記録されないようにすることはできません。これは、ブラウザ クライアントがリクエストでハッシュ マークを超えて何も送信しないためです。JS はリダイレクト URL をインターセプトし、Hash タグの後の内容を解析できます。そのため、追加の中間コードの歌やダンスなしで access_token を返すだけの JS Oauth2 フローが存在します。JS 側でも Client_Secret は必要ありません。これは、javascript 内にパスワードと秘密鍵を配置するときに一般的に嫌われているため、良いことです。
ここで、悪意のある人物がこの中間コードを使用してアクセス トークンを取得するのを防ぐために、Client_ID と Client_Secret が一緒に送信されるため、API サーバーは、あなたが本人であることを認証し、あなたがトークンを引き換える権限を持っていることを確認できます。 access_token のコード。共有秘密に勝るものはありません!
コードの有効期限が切れるまでの使用期間は非常に短いため (基本的には、すぐに access_token と引き換えることを目的としています)、誰かがコードを盗んで Client_Secret をブルート フォースしようとする危険性はあまりありません。
使用の短いウィンドウと client_secret (もちろん ssl 経由) の組み合わせにより、後でクライアント資格情報と交換する が提供されます。
言葉に注意してください.... お勧めしません。
2.3.1. クライアントパスワード
クライアント パスワードを所有するクライアントは、[RFC2617] で定義されているように、HTTP 基本認証方式を使用して、承認サーバーで認証することができます。クライアント識別子は、付録 B に従って「application/x-www-form-urlencoded」エンコード アルゴリズムを使用してエンコードされ、エンコードされた値はユーザー名として使用されます。クライアント パスワードは、同じアルゴリズムを使用してエンコードされ、パスワードとして使用されます。認可サーバーは、クライアント パスワードが発行されたクライアントを認証するために、HTTP 基本認証方式をサポートしなければなりません。
例 (表示のためだけに改行を追加):
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
あるいは、認可サーバーは、次のパラメーターを使用して、リクエスト本文にクライアント資格情報を含めることをサポートする場合があります。
client_id 必須。セクション 2.2 で説明されている登録プロセス中にクライアントに発行されたクライアント識別子。
client_secret 必須。クライアント シークレット。クライアント シークレットが空の文字列の場合、クライアントはパラメータを省略できます。
2 つのパラメーターを使用して要求本文にクライアント資格情報を含めることは推奨されず、HTTP 基本認証スキーム (または他のパスワードベースの HTTP 認証スキーム) を直接利用できないクライアントに限定する必要があります。 パラメータは request-body でのみ送信でき、リクエスト URI に含めてはなりません。
たとえば、本文パラメーターを使用してアクセス トークン (セクション 6) を更新する要求 (表示目的でのみ改行を追加):
POST /token HTTP/1.1
Host: server.example.com
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
認可サーバーは、パスワード認証を使用してリクエストを送信する場合、セクション 1.6 で説明されているように TLS の使用を要求する必要があります。
このクライアント認証方法にはパスワードが含まれるため、承認サーバーは、それを使用するすべてのエンドポイントをブルート フォース攻撃から保護する必要があります。