我們有許多客戶使用我們的API來爲他們的網站提供動力。OAuth：存儲訪問令牌和祕密
我已經開始使用OAuth進行經過身份驗證的API調用的對話。 我們將擁有兩條腿和三條腿。
對於三足式流程，我們還沒有就如何存儲訪問令牌和祕密達成共識。
這個問題的常見方法是讓客戶端將訪問令牌和祕密存儲在他們自己的數據庫中，但這是不可能的，因爲客戶端不想處理代碼更改和實現問題。
其他選項，我們正考慮：
1）保存訪問令牌和祕密在會話保存他們的cookie
2）。
我不確定這些是否是一個好主意。有沒有人有什麼建議？
謝謝。
我假設你正在談論典型的「服務提供商」，「消費者」和「用戶」類型的設置。如果您的消費者（客戶）拒絕做出任何更改，我不知道您是否能夠實施三方oAuth。
會話和cookie可用於保存令牌，但問題在於它是您的客戶（您的客戶）需要保存它們 - 而不是您。對您的API的調用發生在後端，因此在該範圍內沒有可用的會話或cookie。如果您只是進行JavaScript調用，也許這確實起作用，但即使這樣，通常通過代理進行調用，以避免跨域腳本問題。
在這兩種情況下，如果令牌存儲在會話或cookie中，它們將是「臨時」密鑰，當會話或cookie過期時，用戶將不得不重新驗證身份。但就oAuth規範而言，只要用戶不介意重新進行身份驗證，就沒有任何問題。
賈森提到它不可能爲消費者應用程序，以驗證請求，如果他們不存儲所需的認證令牌 - 他們可以將它們存儲在任何他們想要的方式，但這種是等式中需要的一部分。它可以是文件系統，memcache，數據庫，內存。
我看到使用cookie來存儲這些消息的唯一方法是讓消費者應用程序將這些令牌憑證設置爲用戶瀏覽器中的cookie，並且用戶將它們發送回消費者，但每次請求都會發生這種情況 - 但這看起來很荒唐首先，消費者應用程序將再次需要對其代碼進行更改以處理此問題;其次，令牌和令牌密鑰將冗餘地圍繞網絡和用戶的瀏覽器飛行，如果用戶自己決定黑客攻擊。
當我實施3腿oauth時，我遇到了同樣的問題。我使用Google DataStore在Google App Engine &上在線申請我的應用程序以存儲訪問令牌。
但是，配額提及here用於存儲數據&投擲查詢！這是使用Google App Engine的唯一限制！
約1）保存訪問令牌和祕密在cookie
考慮您的客戶在一家網吧後他不清晰餅乾和旁邊的人拷貝這個信息會發生什麼？
我會去DB或PHP會話
我個人不敢使用會話/ Cookie出於安全原因，因爲這是訪問令牌的情況:( – 2011-02-04 09:53:48