我想在我們的基礎架構上實施新的基於REST的API，而OAuth似乎是要走的路。雙腿OAuth - 正在查找信息
對於我們的實現，首先是服務器到服務器的訪問，它將完全不受限制。我相信這被稱爲雙腿授權。
之後，我們希望允許瀏覽器使用該API，這將使我們的授權變爲三段式。
這是否有一個很好的起點？我們如何才能完全授權服務器，並在每條用戶的路上添加受限制的授權？
OAuth規範在這些場景中並沒有真正的幫助，但我相信這意味着我們需要爲服務器到服務器的訪問創建一個永不過期的會話，並且稍後會爲訪問受限的用戶添加常規會話，只有API。
我希望找到更多信息的起點，讓我知道！
對我來說是OAuth嗎？我只是在尋找一個經過驗證的請求系統，並且在這種情況下只有消費者和服務提供者存在。最終用戶不會來玩！
OAuth將最終變得對我們的需求來說太難了。我決定採用Amazon S3的認證方案，因爲它更適合我們的模型。
感謝您的幫助了，雖然找到答案..
請記住區分認證和授權。在一些地方，我相信OP會混合兩者。例如，一旦服務器認證某人，它通常明確或隱含地（使用cookie）提供認證令牌，以便後續請求已被授權。
它取決於服務器證書的最後長度。 計劃很明智，證書將在某個時間點超時。只要客戶端服務器在收到「授權過期」錯誤響應時就準備重新進行身份驗證。
你不想嘗試，因爲提供了「永不過期」會話：
一切都在某些時候到期。例如，如果客戶端服務器斷電或重新啓動，它將如何再次開始訪問應用程序？
您正在創建一個不靈活的系統。他們往往更經常打破。
雅，OAuth可能適合你。
實際上有兩種OAuth規範，3腿版本和2腿版本。 3腿版本是最受關注的版本，它的不是你想使用的版本。
好消息是，雙腿版本完全符合您的要求，它允許應用程序通過共享密鑰授予對另一個應用程序的訪問權限（非常類似於亞馬遜的Web服務模型，您將使用HMAC- SHA1簽名方法）或通過公鑰/私鑰系統（使用簽名方法：RSA-SHA1）。壞消息是，它還沒有像三腳版那樣得到很好的支持，所以你可能需要做更多的工作，否則你現在可能不得不做更多的工作。基本上，雙腿OAuth只是指定一種方法來「簽名」（計算散列）幾個字段，其中包括當前日期，一個稱爲「隨機數」的隨機數，以及請求的參數。這使得很難用來模擬對你的web服務的請求。
OAuth正在慢慢地，但肯定地成爲這種事情的公認標準 - 如果你擁抱它，你將會從長遠來看最好，因爲人們可以利用各種可用的庫來做到這一點。
它比你最初想要的更精細 - 但好消息是，很多人花了很多時間在上面，所以你知道你沒有忘記任何東西。一個很好的例子是Twitter最近發現了社區目前正在關閉的OAuth安全漏洞。如果你發明了自己的系統，你必須自己弄清楚所有這些東西。
祝你好運！
嗨拉里， 一個永不過期的會話是常見的做法，並不意味着我們失去了會話的服務器重新啓動時。會話存儲在多個數據庫和memcached實例中。有了會話，我的意思是一個「持續令牌」。 Facebook使用這個例子。 – Evert 2009-05-19 21:11:34
最後，我們目前的系統使用'API KEY'，它是不安全的，因爲它需要通過線路發送（基於幾個變量的HMAC-MD5會更好），並且api密鑰在任何情況下都不應該最終在最終用戶機器上。這就是爲什麼我去了oauth。 – Evert 2009-05-19 21:13:26