爲我們的Web應用程序設計API時，我們將使用其子域作爲'用戶名'並生成API密鑰/共享密鑰。首先，可以使用子域名作爲用戶名嗎？我看不到產生另一個密鑰的好處。保護API：SSL和HTTP基本身份驗證與簽名
不同的API似乎做的兩件事情之一：
在每個請求的用戶名設置爲子域名和密碼的API鍵。由於我們使用SSL，所以這應該是安全的欺騙。
值得注意的API：Google Checkout，Freshbooks，GitHub，Zendesk
由通常所取得的請求的簽名排序鍵/值對並使用HMAC-SHA1和共享密鑰生成簽名。簽名隨後與請求一起發送，並在另一端進行驗證。
值得注意的API：Google Checkout，Amazon AWS
PS：多數民衆贊成毫無疑問，谷歌Checkout的支持
編輯：剛纔讀的OAuth 2滴簽名支持發送用戶名/密碼通過SSL。
任何人都有什麼意見可以選擇：SSL vs Signature？
通過SSL的HTTP基本驗證對我的研究來說是完全安全的。
畢竟，使用SSL（嚴格意義上的TLS）意味着傳輸層被加密，我們可以安全地假設傳遞過來的任何信息都是安全的並且沒有被篡改。
因此，傳遞用戶名和密碼而不生成簽名就足夠了。
只要存在某種形式的祕密，就可以使用子域名作爲用戶名。
使用共享祕密的好處是，執行請求的'party'不需要知道祕密，它只需要知道簽名來執行請求。例如，如果您希望用戶允許通過瀏覽器進行請求，則這是有益的。
使用S3，您可以創建簽名，將其發送到瀏覽器並直接從瀏覽器上傳到S3。
你也可以使用HTTP摘要，它有兩個好處。您仍然可以在瀏覽器中輕鬆測試API，因爲瀏覽器支持Digest和Basic，並且純文本密碼絕不會通過線路發送。
伊戈爾的答案並不完全正確。儘管TLS確實確保傳輸層是加密和安全的，但它仍不如使用具有相互身份驗證的實例TLS安全，其中客戶端使用數字簽名形式的「強密碼學」進行身份驗證。主要有兩大原因，這仍然比基本身份驗證更好了TLS：
密碼是密碼，我會承擔四分之三的現在7十億人在我們的星球使用30個字符的密碼是完全隨機。我們其餘的人選擇了熵少得多的東西。因此，攻擊者更容易暴力使用密碼而不是數字簽名的服務。
有人可能會爭辯說，對於客戶端數字簽名，還有一個密碼，通常用於訪問私鑰。但是，這與我們使用Basic Auth的情況完全不同：首先，私鑰作爲資源駐留在客戶機器上，因此即使恢復它也只會影響一個人而不是所有人，其次，對於典型的密鑰容器格式（如PKCS＃12）還有用於訪問密鑰的基於密碼的加密。這些算法專門設計用於減慢攻擊者的速度，以減少每單位時間嘗試蠻力的次數，這也是數字簽名的優勢。
毫無疑問的是TLS的基本身份驗證是建立和使用更方便，但對於高度安全的環境我總是喜歡「強加密」在用戶/密碼的解決方案，這是值得的麻煩。
好奇你的想法在潛在的中間地帶：api key over SSL？這使用一個更長的「密碼」，不會被強制強制。但仍然沒有簽署。所以我想它仍然依賴於SSL的100％工作，但是與基本身份驗證集成（如果不是更簡單，1場而不是2場）一樣簡單。 – 2013-01-07 04:10:15
@BrianArmstrong：我同意。更好的熵，但仍然需要SSL。不過，我真的很喜歡客戶端認證方案的分散化方面。另一方面，客戶機可能比服務器更容易滲透。 – emboss 2013-01-07 14:10:56
OpenSSL的Heartbleed問題說明了僅依靠SSL來保護API的潛在隱患。根據API的使用情況以及SSL傳輸是否受到影響的影響，可能需要採取其他安全措施，如浮雕的答案中所述。
我想指出一些在security.stackexchange.com中提到的事情，因爲你說「基於SSL的HTTP基本驗證對我的研究是完全安全的。」。你可能會爭辯說，下面的第3點和第4點對於REST API來說很少有效，但這取決於它們是如何實現的。
「有與HTTP基本認證的幾個問題：
其中，使用SSL只解決了第一個。即使如此，SSL只會保護網絡服務器 - 任何內部路由，服務器日誌記錄等都會看到明文密碼。
因此，如同看待整個圖片的任何重要內容一樣。 HTTPS在傳輸過程中保護密碼嗎？ - 是的。
那夠了嗎？通常，不。 （我想說，始終沒有 - 但它確實取決於你的網站是什麼，以及如何安全的需要來定）」
回答上一個古老的線程是沒有人真正觸及要點
因爲它們依賴於信任鏈已被證明越來越多的時候容易MiM attacks SSL/TLS是像所有的PKI根本性的缺陷：
證書頒發機構已經和可被黑客攻擊在許多一例是蒙特卡洛蒙受損的情況下的DigiNotar hs在違規被確認之前所有證書被撤銷。與此同時，伊朗政府已經爲google.com，facebook.com，twitter.com等製造了完美有效的SSL證書。
公司的代理過濾工具，如Zscaler，可以即時解密和重新加密所有流量用於未指定的「安全目的」。見this question/answer on SO
錯誤最常見的SSL實現（OpenSSL的）被發現所有的時間（但事情應該隨着時間的推移變得更好？）
因此大玩家不喜歡依靠SSL只有：
在這種情況下，一個HMAC令牌不給你保密但不會允許任何人對您，對間諜使用您的憑據僞造請求，如果你只是通過他們六這將是微不足道的，否則基本身份驗證。
到PKI模型的替代方法是不依賴於一個單一的權威驗證證書的真僞，但Web of trust而是由廣大 提供的意見 - 知名和值得信賴的同行或 - 知名但不一定值得信賴的同行
這種模式仍然不完美，雖然，因爲它是受到臭名昭著51% attack完全一樣的比特幣Blockchain（這是一個分佈式的信任模型的例子）
謝謝，但是如果使用共享的祕密當然，做請求的一方必須知道這個祕密，這樣才能計算出簽名回覆！ – Marcus 2011-04-01 09:59:22
簽名的計算可以在服務器上完成，然後可以將sig發送到執行實際請求的不同客戶端。看一下AWS身份驗證，我喜歡他們的身份驗證方法，並且可以*將它按原樣應用到您的API。比開發你自己的更好。 – Evert 2011-04-01 10:53:10
好吧，我想我已經在這裏回答了我自己的問題。 OAuth 2.0使用沒有簽名的SSL，我認爲SSL上的任何內容都很安全。 – Marcus 2011-04-01 13:18:08