9

我正在嘗試爲我的網站實施OpenID身份驗證。這裏的情景:
我希望用戶能夠只使用OpenID的存儲必要的OpenID信息

  • 登錄(用戶可以只獲得通過訪問OpenID提供商驗證無需創建電子郵件地址和密碼定製的賬戶),
  • 通過電子郵件/密碼(用戶通過填寫​​表格在網站上註冊)
  • 將開放標識附加到他/她的帳戶(openid +爲一個帳戶的電子郵件)。

現在我不知道我應該存儲什麼憑證來存放開放標識。並不確定數據庫架構。這裏的數據庫模式:當用戶登錄時,無論是使用OpenID /自定義成員資格

Table: Users 
UserId => PK 
... => Custom info. Not related to authentication. 

Table: Authentication 
AuthenticationId => PK 
LoginId => (when custom site membership => email address) (when openId => openid unique address) 

UserId => FK to Users. 
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address) 
Password => filled when using custom membership. empty when using open id. 

現在,我只看驗證表格,並查找證書並獲得相應的用戶。如果沒有用戶存在,我創建一個新用戶並在認證表中添加一個條目。

  • 主要問題:是存儲ProviderLoginId(見上述意見,看看有什麼被存儲在這些領域)足夠的存儲OpenID認證的?我是否應該存儲任何其他數據,以便在用戶返回時我可以根據我保存的數據對他/她進行身份驗證?

  • 您是否建議使用其他更高效的方法來執行此操作?
    謝謝。

回答

5

爲openid用戶存儲ClaimedIdentifier - 不是提供者地址。聲稱的標識符是OpenID協議驗證的用戶唯一性,也可能提供跨OpenID提供商的可移植性。另外,由於OpenID 2.0的聲明標識符可能會被OpenID Connect(OpenID 2.0的未完成後繼者)所棄用,因此記錄OpenID提供商端點URI以及由OpenID提供的電子郵件地址也可能符合您的最佳利益。提供者在用戶記錄中。目前,而不是將這些用作身份驗證流程的一部分,但通過記錄它們,您可以稍後確定哪些電子郵件地址是您「信任」的(即,假設您決定Google聲明的電子郵件地址值得信賴),以及允許用戶使用該已驗證的電子郵件地址將其賬戶遷移到OpenID Connect賬戶。這也可以緩解您的網站領域(通常爲http://yourdomainname.com)發生變化的危險,並可能導致您的所有Google用戶聲明的標識符發生變化,這些變化只能通過他們的電子郵件地址真正恢復。

我也建議你爲不同的auth類型使用不同的表格。這裏有幾個優點。最重要的一點是,從體系結構上講,它使得在網站中引入一個安全漏洞變得更加困難,該安全漏洞可能允許某人在用戶名字段中輸入OpenID(例如),並輸入空白密碼並將其顯示爲數據庫匹配和登錄沒有任何真正的認證發生。其次,它提供了一個更靈活的模型,以便您希望添加第三種身份驗證機制,而不是使所有用戶的「身份驗證」表水平增長。例如,OAuth 2.0和「OpenID Connect」每年都會爲您的站點引入新的身份驗證類型,並且添加新表格以處理新類型的數據看起來更合適。

+0

我刪除了'Provider'列,並添加了'bit'類型的'IsOpenId'。什麼是分離認證表(用於openid和定製)的優點[而不是去除不必要的'密碼'列openid認證]? – Kamyar

+2

我加強了我對你的回答。 –

+0

完美!謝謝。 – Kamyar

1

我們只是存儲openid聲明url。您可能希望向提供者請求其他信息,例如用戶的姓名。最重要的是分離成員資格和認證。

我們的模式是

Profiles 
-------- 
UserId 
FirstName 
LastName 
etc. 

Users 
----- 
Username 
Password 

Profiles.UserId簡單來說就是存儲任何用戶內部用戶名或OpenID的要求的URL,這取決於他們如何註冊一個字符串屬性。

成功驗證後(使用內部用戶名/密碼或外部提供程序),我們只需使用其內部用戶名或其聲明網址來設置其身份驗證Cookie。獲取用戶的配置文件然後就是找到配置文件的位置(UserId == User.Identity.Name)。

這樣做的好處是用戶可以選擇在任何時候更改他們的身份驗證方式(可能會切換到內部帳戶或使用不同的提供商)。