Facebookからaccess_tokenを取得するには、app_id、許可リクエスト後にcode、アプリのsecret_keyを送信する必要があります。`access_token`を得るために` client_secret`を送信するのはなぜですか？
なぜでしょうかEVERは私の秘密鍵を送信しますか？これはまったく危険なようです。これはOAuth 2.0仕様の要件ですか？
関連する質問として、私の要求がすでにconsumer_keyで署名されている場合、app_idを送信する必要があるのはなぜですか？
私は実用的なアプリを持っている、私はこれらの要件を理解していない。
これはOAuth 2.0 spec, section 4.1.3の要件です。
クライアントタイプは、機密であるか 節で説明したように、クライアントの資格情報 （または割り当てられた他の認証要件）、は 認証サーバで認証を受ける必要があり、クライアントが発行された場合3.2.1
section 3.2.1は、section 2.3を指す。具体的には、section 2.3.1は言う：
また、認証サーバは、次の パラメータを使用してリクエストボディで クライアント証明書などの可能：
は
REQUIRED. The client identifier issued to the client during the registration process described by Section 2.2.client_secretをCLIENT_ID
REQUIRED. The client secret. The client MAY omit the parameter if the client secret is an empty string.
実際にOAuth 2.0が提供する他の方法がありますが、このアプローチを選択することで、Facebookは仕様内に収まります。今なぜ Facebookはこのアプローチを選んだ、Facebookはおそらく答えることができます。
'client_secret'は' consumer_secret'とは違うはずですか？ 'consumer_key'と' consumer_secret'が提供するものを超えて、 'client_id'と' client_secret'が何を供給しているのか分かりません。 –
クライアントはコンシューマです。したがって、 'client_secret'はFacebookがApp Secretと呼ぶものです。 'client_id'は、FacebookがApp ID/APIキーを呼び出すものです。あなたの要求は、その過程であなたの鍵で署名されていません。パラメータは、トークンを要求するときにアプリを認証するために使用されます。 – kongo09
秘密鍵が送られることは非常に奇妙です。これまでそれがSECRETキーなのです。識別子、PUBLICキー（オプション）、および秘密キーが必要です。秘密鍵は、識別子と公開鍵に署名するために使用されます。しかし、OAuthは、すべての最終的なセキュリティとしてSSLを検討しています。したがって、認可サーバーと通信するときは常にTLSであるため、気にしません。 （通常、MLSでは秘密鍵が使用されます。 – BradLaney
Oauth2の要件のほかに、あなたが本当にあなたが主張しているかを確認するために、この手順でclient_secretを使用する必要があります。
それはすべて、それがあるように、プロセスがある理由に沸く
...「コード」あなたが戻って最初のリクエストから取得するには、それ自身のセキュリティの観点からはかなり弱いです。リダイレクトリンクであなたのところに乗っ取られる可能性があります。リダイレクトリンクは、SSL保護なしでリンク先ページに頻繁に行きます。たとえあなたのサイトが100％HTTPSでも、すべてが完全に安全ではありません。誰かが、Webサーバーのアクセスログに記録されるリクエストURLを調べることでコードを見つけることができます。
バッキンガム宮殿のこの側面であなたのサーバへのアクセスを制御している場合でも、何年も前からハイテクロデオに乗っていたら、ある時点で誰かが "アーカイブ"あなたのログは理想的には安全ではありません。おそらく、スターバックスで残したUSBキーに...
サーバーサイドのAPIフローを使用している場合は、これを避けてはいけません。クライアントブラウザ内で実行されているJavascriptとは異なり、ブラウザクライアントはリクエストとともにハッシュマークを超えて何も送信しないため、ハッシュ後に一時コードを追加してログが記録されないようにすることはできません。 JSはリダイレクトURLを傍受し、ハッシュタグの後にパースすることができます。そのため、追加の中間コードの歌とダンスを除いてaccess_tokenを返すだけのJS Oauth2フローがあります。 JSの側にもClient_Secretの必要はありません。これはjavascriptの中にパスワードと秘密鍵を置いたときに一般的に気にならないものです。
悪意のある人がこの仲介コードを使用してアクセストークンを取得しないようにするには、Client_IDとClient_Secretが一緒に送信されるので、APIサーバーがあなたを認証できます。 access_tokenのコードを引き換えるための承認。共有秘密を打ち負かすものはありません！
コードの期限が切れる前に非常に短いウィンドウが使用されているため、基本的にはaccess_tokenの即時使用のために使用することを意味します。コードを盗んで、ブルートフォースを試みる危険性があります。Client_Secretはあまりありません。
使用の短いウィンドウと（もちろんover SSLの）client_secretの組み合わせは、あなたが後でないことをお勧めしますクライアントの資格情報
お知らせ言葉....と交換されています。
2.3.1。クライアントのパスワード[RFC2617]で定義されているクライアント・パスワードを所持して
クライアントは と認証サーバを認証するためにHTTP基本 認証方式を使用することができます。クライアント識別子は、 付録Bの 「application/x-www-form-urlencoded」エンコーディングアルゴリズムを使用してエンコードされ、エンコードされた値がユーザー名として使用されます。クライアントの パスワードは同じアルゴリズムを使用して暗号化され、 パスワードとして使用されます。認証サーバーは、 クライアントパスワードを発行したクライアントを認証するためのHTTP基本 認証方式をサポートしなければならない（MUST）。
例えば（表示のみの目的のために余分な改行付き）：
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
また、認証サーバは、次の パラメータ使用して、リクエスト・ボディに クライアント証明書などのサポートがあります。
をclient_id が必要です。 の間にクライアントに発行されたクライアント識別子で、第2.2節で説明した登録プロセスです。
client_secret が必須です。クライアントの秘密。クライアントシークレットが空文字列の場合、クライアントは パラメータを省略することがあります。2つの パラメータを使用して、リクエスト・ボディでクライアント証明書などの
はお勧めしませんし、直接HTTPベーシック認証方式（あるいは他の パスワードベースのHTTP認証スキーム）を利用すること できないクライアントに限定されるべきです。パラメータは しか要求本体で送信されず、 要求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。
このクライアント認証方法にはパスワードが含まれているので、 認証サーバーは ブルートフォース攻撃に対してそれを利用しているエンドポイントをすべて保護する必要があります。
[OAuth 2.0 spec]（http://tools.ietf.org/html/draft-ietf-oauth-v2-21）では、アクセストークンを要求する際に秘密鍵を送信する必要はありません。 –