7

這似乎是一個重複發生的問題,因爲我似乎在過去幾年中對移動應用程序感興趣。除了Web用戶之外,我想驗證和授權移動用戶。我需要使這一切足夠無縫,以便用戶可以輕鬆擁有網絡帳戶而不會中斷他們的數據。我希望解決方案成爲主題的架構,而不是針對任何語言/框架。移動和Web用戶身份驗證/授權體系結構

要求/假設

  1. 移動用戶必須能夠使用本地應用程序,而不登錄,包括對促進內容(標記收藏,上傳照片等)。
  2. 即使沒有指定帳戶憑證,移動用戶也應該安全且唯一地對Web服務進行身份驗證。
  3. 移動用戶可能有多個設備,這些設備將彼此不知道。
  4. 移動用戶應該能夠註冊/登錄,它應該將任何內容放入該賬戶的所有權。對於隨後登錄的每個帳戶應該發生此「同步」。
  5. 帳戶是在移動設備還是網絡上創建應該沒有關係。

架構考慮

  1. NO襯衫,沒有鞋,NO LOGIN =沒有貢獻。需要登錄才能提供任何形式的內容。這可以防止需要將設備帳戶與主帳戶「同步」。只需要一個用戶名/密碼+令牌以便設備登錄。服務器對象:用戶,角色
  2. 多設備自我認證。服務器與設備協商並交付設備存儲的證書。每個設備都會進行自我認證並與匿名賬戶關聯,直到註冊/登錄發生。如果發生註冊,匿名賬戶將轉換爲已知賬戶。如果登錄發生,來自匿名賬戶的內容會被轉移到已知的賬戶,然後被丟棄。丟失自我認證詳細信息的設備將獲得新的認證詳細信息,而之前的匿名帳戶將被放棄(然後希望稍後會丟棄),並且因爲它從未轉換爲已知帳戶而不可恢復。服務器對象:用戶,角色,設備

您認爲什麼是一個好的解決方案?其中之一還是其​​他?

回答

0

2號作爲基本決定是足夠好的。用戶討厭註冊;)因此,無需註冊即可使用服務的能力是個好主意。

您可以使用GUID/UUID來識別設計。並在用戶登錄之前將其用作匿名登錄。

但是如果2個(或更多)人使用1個設備該怎麼辦?或者設備會丟失,被盜? 我認爲這些情況中沒有一點涉及這些情況。

我不知道你建築師是什麼樣的網絡服務,所以不能建議更多。

2

我想提出一個類似於2的想法。

爲每個移動設備生成一個UUID。當用戶生成內容並將內容發送到服務器時,它將用於在稍後出現的設備上識別設備。

如果在以後的任何時間用戶想要創建一個網絡帳戶,他可以在網絡上或在設備上註冊。如果用戶已經擁有一個網絡帳戶,他可以選擇在他的移動設備上提供一次(或多個設備)的現有憑證,並將設備鏈接到他在服務器端的網絡帳戶。

在服務器端,我會允許兩種不同類型的實體作爲身份:通過憑證進行身份驗證的Web用戶(我認爲是OpenID)以及通過GUID進行身份驗證且無用戶干擾的設備。當然,一個網絡用戶實體可能擁有多個設備實體。當用戶選擇將他的設備鏈接到現有帳戶時,設備實體會鏈接到帳戶。內容通常與身份相關聯。

用戶和設備之間的鏈接保持不變,也可用於顯示內容的來源。

您不需要爲移動用戶創建/刪除/轉換具有生成憑證的帳戶。您也不需要將憑據存儲在移動設備上。

仍然存在一些安全問題,這取決於應用程序上下文的關鍵性。沒有任何安全措施,攻擊者會發現濫用UUID很容易。

2

我認爲這是從錯誤的方向看的。在服務器上定義一個由任意值定義的標識。可能只是一個DB序列。將任何人口統計信息(姓名,電子郵件...)和使用歷史記錄與此身份相關聯。

另外,在服務器上定義一個認證實體。這可能是一個用戶/密碼。它可能是一個設備GUID/UUID。它可以是像OpenID這樣的聯邦ID。給定的身份可以具有(並且通常在您的用例中)多個關聯的認證實體。很可能有多個相同類型的身份驗證身份。 (例如,我的智能手機的GUID,我的iPad的GUID ...)

您的前端(無論是基於Web還是基於應用)使用定義的API來驗證用戶;使用前端支持的任何機制。

在某些情況下(尤其是原生應用程序),未知ID的呈現會觸發創建新身份。但是,正如有人指出的那樣,在這種情況下,您應該詢問用戶是否想要連接到現有身份。他們需要提供身份驗證(一次)以建立連接。

另一點,無論服務器用於唯一指定身份,應該是提供給客戶端的值爲從不。客戶只知道認證機制及其數據。也就是說,GUID/UUID,用戶名/密碼,...

除了上面列出的技術之外,像OAuth這樣的東西比本地生成的GUID更安全。這些是一個:易於確定或b:容易丟失。如果該值具有高度可預測性(如電話號碼),則很容易被欺騙。如果它是在運行時生成的,並且包含一個難以預測的值,比如首次生成時的當前時間的散列值,那麼它必須存儲在設備中,並且如果設備被擦除,則很容易丟失。可以生成良好的GUID,但它們通常是非常類型化的設備。像從ROM,IMEIs檢索到的設備序列號......這很容易實現。但是,更具體的設備依賴比我可能會感到舒服。

我在整個方法中看到的最大的障礙是,允許現有設備(無用戶名/密碼)用戶坐在PC瀏覽器並連接到他現有的帳戶將會很尷尬。

+0

我真的很喜歡你的思路。我不確定它是否真正說明了解決這個問題的常用技術,但我非常感謝您的迴應。 (請注意,我在2010年閱讀了此回覆,但現在我不得不通知您,因爲它已被讚賞和有用) – 2012-03-29 07:51:10

-3

一種解決方案是使用生物特徵。如果移動設備具有生物測定傳感器,例如指紋閱讀器,則用戶將在購買時向設備註冊生物測定(僅限於 - 由於隱私問題)。可以編寫應用程序,以便每個安全事務都需要用戶驗證生物特徵。

這似乎沒有太多關閉。摩托羅拉Atrix有一個指紋傳感器...

+0

此回覆並未真正解決所提交的帖子。當然,生物識別技術可以幫助識別用戶,但將設備和用戶身份驗證連接到後端仍然需要一些設計考慮因素。我還沒有遇到一個完美的解決方案。 – 2012-03-29 07:52:22