瞭解在三方OAuth會話中使用用戶標識嗎？

Question

今天經過真正的大腦彎曲會議後，我覺得我很瞭解三腳OAuth身份驗證。我仍然無法理解的是使用用戶ID。到目前爲止，我看到的例子都似乎只是在示例腳本的頂部任意分配一個用戶標識並去。這讓我困惑。

我見過的大多數示例代碼似乎圍繞使用用戶標識和OAuth服務器的使用者密鑰來管理OAuth「會​​話」的概念（在引號中，因爲我沒有試圖將該術語與一個瀏覽器「會話」）。例如，我見過的數據庫示例代碼根據用戶標識和消費者鍵字段值存儲和檢索涉及的標記和其他信息。

我現在是在不確定性，其中的理解一些競爭片段競爭和相互衝突的那種狀態：

1）如果我的OAuth的會議細節記錄或「OAuth的店」查找的理解是正確的，通過消費者密鑰和用戶ID字段，那麼是否並非要求我爲使用與OAuth服務器連接的應用程序的每個用戶擁有完全不同的用戶ID？

2）如果＃1是正確的，那麼我該如何避免爲不同的用戶創建自己的用戶帳戶，我試圖避免這種情況？我正在嘗試編寫用作啓用OAuth服務的前端的軟件，因此我不需要擁有自己的用戶記錄和伴隨的維護難題。相反，我只是讓OAuth服務器處理難題的結尾。然而，似乎後來我的方法的缺點是，我不得不重新授權用戶的每個會話，因爲沒有我自己的持久用戶帳戶/ ID我無法查找以前授予的「良好撤銷」訪問令牌，正確？

3）令我困擾的是，我已經閱讀了一些OAuth服務器，它們在請求未授權令牌期間不允許傳遞動態指定的回調URL，從而使用戶密鑰和用戶ID回傳給自己不可能。相反，當您註冊爲開發人員/消費者時指定回調URL，就是這樣。幸運的是，我正在處理的OAuth服務器確實允許使用該功能，但是如果我正在處理那個不支持的功能，那麼這不會引發巨大的猴子扳機來使用使用消費者密鑰和用戶ID對的整個想法索引OAuth會話詳細信息？

Answer 1

我試圖告訴我的觀點上，你提出的，並希望將清除的東西一點點問題...

首先，想法是OAuth的服務器保護一些API或數據，其第三方應用程序（消費者）想要訪問。

如果您在OAuth服務器後面的API上沒有用戶帳戶或數據，那麼爲什麼消費者應用程序想要使用您的服務 - 將從您那裏獲得什麼？話雖如此，我無法想象一個場景，你有一個OAuth服務器，並且你沒有用戶帳號。

如果您只是想使用OAuth登錄用戶，而無需通過API提供用戶數據，那麼最好使用OpenID，但您必須擁有用戶帳戶。

你的觀點是正確的，你通過消費者密鑰和（你的）用戶ID進行查找，這是因爲協議設計。

的一般流程是：

1. 的OAuth服務器（提供者）的問題未授權的請求令牌消費應用
2. 消費者向最終用戶授權的OAuth的服務器請求令牌（提供商）
3. 在最終用戶授權令牌之後，訪問令牌被頒發並提供給使用者（我在此跳過了一些細節和步驟，因爲它們對於我想說的並不重要，例如，使用者在結束）
4. 關於a uthorization步驟，它是您的OAuth服務器創建並保存爲一對 - 本地用戶（本地用於提供商）授權哪個用戶（用戶密鑰用戶ID對）。
5. 之後，當消費者應用程序想要從提供程序訪問最終用戶DATA或API時，它只發送訪問令牌，但不發送用戶詳細信息。
6. 然後，OAuth服務器（提供者）可以通過令牌檢查哪個是已授權該令牌的本地USER ID，以便將該用戶的用戶數據或API功能返回給使用者。

我不認爲你可以沒有本地用戶在你身邊，如果你是一個提供者。

關於回調問題，我認爲如果您使用動態或靜態（註冊時）回調URL來處理與使用者密鑰和用戶ID相關的OAuth會話的方式，則沒有區別。 OAuth規範本身並沒有強制要求有一個回調URL--它是一個可選參數，每次發送都是可選的，或者是可選的，只在開始時註冊一次。 OAuth提供商決定哪個選項最適合他們使用，這就是爲什麼有不同的實現。

當提供者在數據庫中有一個靜態定義的回調URL，與消費者連接時，它被認爲是更安全的方法，因爲最終用戶不能被重定向到「假」回調URL。例如，如果一個邪惡的人竊取了GreatApp的消費者密鑰，那麼他可以讓自己成爲消費者EvilApp，它可以模仿原始的GreatApp並將請求發送到OAuth服務器，因爲它是原始的。但是，如果OAuth服務器僅允許靜態（預定義）回調URL，則EvilApp的請求將始終在GreatApp回調URL處結束，EvilApp將無法獲得訪問令牌。

Answer 2

這是一個答案the question by Lode：

是不是正確的，不僅是供應商需要有用戶ID（這聽起來邏輯），而且客戶端？因此，客戶端（使用OAuth作爲登錄系統）需要先創建一個用戶（帶有ID），然後才能通過OAuth服務器成功進行身份驗證。當身份驗證失敗或未授予訪問權時，使您擁有大量空的用戶帳戶。

它可以使用爲用戶認證的OAuth沒有在消費者應用程序有本地戶口，但你必須有某種會話機制（餅乾/獲取PARAMS），以便有一些內部會議上表示你將在其中存儲oauth_token。例如，如果有人登錄到您的Web應用程序，並且您的應用程序是某個OAuth提供程序的使用者，則必須在您的站點爲最終用戶創建本地會話：例如使用cookie。然後，將最終用戶發送給OAuth提供者以授權令牌，以便您的應用程序可以從提供者處獲得受保護的資源。目前你對用戶一無所知，你不關心他的身份。你只是想使用提供者提供的一些受保護的信息。

當用戶成功授權後，來自於供應商回來，帶回的oauth_token，您現在可以存儲此令牌，您先前爲用戶創建會話。只要你保持你的會話（如果進一步請求資源需要這個令牌），你可以認爲最終用戶已經登錄了。在你刪除他的會話或令牌到期的那一刻，你可以考慮他不再登錄。這樣您就不必製作自己的用戶數據庫表或存儲機制。

但是，如果您需要在應用程序中擁有關於用戶的一些持久性信息，該信息將在用戶會話（登錄）之間使用，則必須維護自己的用戶以便知道與哪個用戶關聯信息。

至於的OpenID和OAuth之間的區別 - 從本地賬戶的角度來看，沒有什麼區別。全部都是一樣。所不同的僅僅是與OpenID的同時通過OAuth您收到一個令牌，你立即獲得一些基本的用戶信息（電子郵件等），你必須做出一個更請求來獲取用戶的基本信息（電子郵件等）

但是，如果您打算使用OpenID或OAuth，則與本地帳戶無關。