的OAuth2用戶映射和失去我的餅乾

從請求/響應機制和授權/身份驗證往返（我想我underdstand）我奮力

除了如果（實際上當，而不是如果）用戶殺死我可能在瀏覽器上丟棄的任何cookie（加密的或其他的），則將MyUser對象（可能包含的任何內容）映射到OAuth令牌。

我在原始登錄中獲取MyUser信息（稱爲「註冊」爲我的網站），但現在MyUser回來了，所有的cookies都消失了，所以他只是'用戶'。足夠公平，用戶必須再次進行OAuth登錄，但現在我無法將新令牌/祕密與MyUser數據相關聯。

我錯過了什麼？

---編輯八月2/2012 -----

讓我重申這一點（我敢肯定我是厚約這一點，但我猜這是在這裏什麼）：

由於在回帖中指出，每個OAuth提供者都有自己的機制。我們可以導航這些並獲取用戶的訪問令牌。

可以說英雄在我的網站上使用Facebook註冊。 FB返回他的FB UserID和Name以及Access Token。我們是足夠聰明的請求，並得到他的FB電子郵件，我們問他一些其他註冊q的值讓他在那之前，我們把它保存在我們的數據存儲（鏈接到我們自己的用戶記錄）：

OurUserId : 1234 
oAuthProviderName : Facebook 
oAUthProviderUserId: xxxxx 
oAuthProviderUserEmail: [email protected] 
oAuthProviderUserName: iBeHero 
oAuthToken: entracingly-unique-string-of-goop 
oAuthSecret: moredata 
.... etc.

，並設置一個餅乾，以識別他爲我們的用戶＃1234.

現在英雄消失，出於某種原因殺死他的餅乾，然後回到我們身邊。

現在他決定用Twitter登錄。我沒有cookie，所以我不知道他是誰，然後我們再次完成這個過程。

對我來說，他看起來像一個新用戶，所以一旦Twitter給我一個令牌，我開始問他註冊問題，顯然不對。

原來，Twitter並沒有返回電子郵件地址，所以我無法與之相匹配，即使他們這樣做（我認爲幾乎所有人都這樣）英雄似乎有多個電子郵件。

在我看來，我在兩個（或多個）登錄之間唯一的聯繫是我設置的沒有被刪除的cookie。

我們是說整個OAuth2.0機制都掛在這個上面嗎？我無法相信那是對的，但是看不到另一種方式，所以我必須錯過某些東西，是的？

來源

2012-08-02 Serexx

如果您也使用OAuth作爲登錄機制，請確保與您交談的提供商有某種方式可以爲用戶返回穩定的ID。該ID是您用於在數據庫中查找用戶的關鍵。

不同的提供商有不同的方式來做到這一點。對於Google，有關如何使用OAuth 2.0進行身份驗證的詳細信息是here。對於Twitter，他們使用OAuth 1.0並在交換訪問令牌的代碼時返回用戶ID。 Facebook也有自己的做法。

來源

2012-08-02 17:39:32

感謝您的回覆，不完全是我所問，雖然我可以看到爲什麼..我要編輯的問題更清楚！ – Serexx 2012-08-02 20:04:19

@Serexx在編輯完成後，Steve的回答仍然完全正確。 OAuth是* Authorization *的標準。您有權代表用戶訪問數據。通過訪問標識用戶的數據（取決於提供商，而不是OAuth標準的一部分），您可以*認證他（例如通過請求他的用戶ID）。因此，只需詢問用戶ID，檢查ID是否已存在於您的數據庫中，然後對其作出反應（例如，設置新的cookie）。 – 2012-08-02 20:50:24

當用戶第一次使用Facebook登錄（認證自己並授權我）時，我現在被授權從Google獲取數據，但除非我錯過了一點（很可能），Google不會給我任何可以讓我在我的數據存儲中識別原始的基於Facebook的記錄的東西。爲了簡化，爲什麼這是不正確的？當你說'請求用戶名'時，你是說再次詢問/ user /？ – Serexx 2012-08-03 05:21:29

的OAuth2用戶映射和失去我的餅乾

回答

相關問題