使用twitter憑據作爲站點憑據的最佳實踐

該任務很簡單。我想使用「使用Twitter登錄」作爲用戶的憑據，允許他們訪問網站的受限區域並將其操作與其帳戶相關聯。使用twitter憑據作爲站點憑據的最佳實踐

我可以在Twitter上簽名。我得到一個ID，用戶名，oauth標記，祕密標記，...

現在讓我們說，用戶然後做出特定於網站的行爲，如對調查的投票。我想將投票歸因於他們的賬戶。

我應該向服務器發送什麼信息來證明投票是來自Twitter用戶的投票？

例如，是否足以發回Twitter ID和投票？其他人是否可以獲得此ID的保留，然後開始以用戶名義進行投票？

我應該向服務器發送Twitter ID，oauth令牌和祕密令牌嗎？再次，我如何驗證這些憑據是否有效？服務器是否需要在每次特定於站點的操作後向Twitter發出呼叫以驗證這些憑據？這似乎過分。

我是否讓服務器驗證一次憑據，然後發回一些隨機會話密鑰，然後在每次請求剩餘會話後驗證會話密鑰？

這類事情已經在數千個網站上實現，所以只是想知道那個常識解決方案是什麼。對不起，如果這個問題之前已經問過。在這種情況下，參考答案將不勝感激。

而且，我在node.js中和的情況下使用hello.js有一個堆棧特定的解決方案

感謝

來源

2015-02-23 kane

我意識到我的假設存在固有的問題。 hello.js允許我在前端進行身份驗證（在第三方代理服務器的幫助下）。因爲我的服務器從來沒有看到令牌交換，所以它依賴於客戶端來告訴它它已經被認證，這是我使用這種方法的地方。取而代之的是，我最終使用了後端認證的passport.js – kane 2015-02-27 07:42:27

你的會話密鑰的想法是好的。它將保證進一步請求（例如投票）和Twitter用戶ID之間的關聯。唯一的問題是，如果存在中間人，則他們捕獲會話密鑰並可以重播請求。這可以通過使用HTTPS來解決，它保證沒有人與傳入的請求混淆，從而保證與用戶的關聯。而且由於會話密鑰很短，所以它們不可能用於未來的攻擊。

來源

2015-02-23 03:42:17 amahfouz

我提出的會話密鑰解決方案中唯一出現的問題是，它導致兩個令牌驗證，一個在客戶端，當用戶使用Twitter登錄時，以及然後再次在服務器端生成隨機會話密鑰。想知道是否有更高效的方法 – kane 2015-02-23 07:52:19

好吧，OAuth已經是一個多步驟的過程，所以與額外的安全性的好處相比，這個額外步驟的成本實際上可以忽略不計。 – amahfouz 2015-02-23 19:52:52

不幸的是，一些社交網絡對我可以做多少令牌驗證有限制。例如Twitter每15分鐘限制到15次，所以這不會在生產網站上擴展 – kane 2015-02-27 07:40:50

使用twitter憑據作爲站點憑據的最佳實踐

回答

相關問題