爲了從Facebook獲得access_token，您必須傳送您在授權請求後收到的app_id,code以及您的應用的secret_key。爲什麼我應該傳輸`client_secret`來獲得`access_token`？
爲什麼我會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表示：
可替換地，授權服務器可以允許使用以下 參數包括在請求體的 客戶端憑證：
CLIENT_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可以回答。
'client_secret'應該與'consumer_secret'不同嗎？ 我不明白「consumer_key」和「consumer_secret」提供的'client_id'和'client_secret'提供的內容。 –
客戶是消費者。因此，'client_secret'就是Facebook所說的App Secret。 'client_id'是Facebook調用App ID/API的密鑰。您的請求沒有在過程中使用您的密鑰簽名。這些參數用於在請求令牌時驗證您的應用。 – kongo09
祕密鑰匙將被髮送是非常奇怪的。 EVER。這就是爲什麼它是一個祕密鑰匙。應該有一個標識符，PUBLIC密鑰（可選）和密鑰。祕密密鑰用於簽署標識符和公鑰。但是OAuth正在將SSL視爲最終所有的安全措施。所以它不關心，因爲當你與授權服務器通信時，它總是通過TLS。 （通常密鑰用於MLS。 – BradLaney
除了作爲Oauth2的要求之外，還需要在此步驟中使用client_secret來驗證您確實是您聲明的對象。
這一切都歸結到爲什麼過程就像是......
的「代碼」，你得到的第一個請求回是從它自己的安全角度來看，相當薄弱。它可能會在重定向鏈接中被劫持，這是我經常看到的沒有SSL保護的登錄頁面。即使您的網站在100％HTTPS的情況下，一切都不完全安全。有人可以通過查看在Web服務器的訪問日誌中記錄的請求URL來查找代碼。
即使你擁有最緊密的安全環境，白金漢宮的這一側控制着你的服務器，如果你已經騎了幾年的技術牛仔隊，你知道有人正在某個時刻「存檔」你的日誌某處不夠理想。可能在他們留在星巴克的USB密鑰上...
如果您使用的是服務器端API流程，則不能避免這種情況。與在客戶端瀏覽器內運行的Javascript不同，您不能在哈希之後添加臨時代碼以防止它被記錄，因爲瀏覽器客戶端不會在請求之後通過哈希標記發送任何內容。 JS可以攔截重定向Url，並在Hash標記之後解析出東西，這就是爲什麼JS Oauth2流只是簡單地返回access_token而沒有額外的中介代碼歌曲和舞蹈。沒有Client_Secret需要在JS方面，這是很好的，因爲當你把密碼和祕密密鑰放在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 Basic 認證方案，以認證發佈了 客戶端密碼的客戶端。
例如（額外換行符僅用於顯示目的）：
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3
可替換地，授權服務器可以支持使用以下 參數包括在請求體的 客戶端憑證：
client_id 需要。在第2.2節描述的註冊過程中， 期間發給客戶端的客戶端標識符。
client_secret REQUIRED。客戶的祕密。如果客戶端密碼是空字符串，則客戶端可以省略 參數。
包含在使用所述兩個 參數請求體的客戶端憑證是不推薦的，並且應該被限制到客戶端無法 直接利用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
授權服務器必須要求使用TLS，如 第1.6節中所述，使用密碼驗證發送請求時。
由於此客戶端身份驗證方法涉及到密碼，所以授權服務器必須保護使用它的任何端點，以對抗 蠻力攻擊。
[OAuth 2.0規範]（http://tools.ietf.org/html/draft-ietf-oauth-v2-21）在請求訪問令牌時不需要發送密鑰。 –