OpenUser 數字身份識別協議

受權

OpenUser 由 喻恆春 創做，採用 知識共享 署名 3.0 未本地化版本 許可協議 進行許可。

歷史

此文最先發表在個人 老博客。原文章只是籠統的想法。博客完全轉到 OSC。準備繼續探討這個話題。文章內容會不斷完善修正。

簡述

數字身份識別框架已經有了大名鼎鼎的OpenID，更有Mozilla推出的BrowserID 都是流行的數字身份識別系統,這兩個有什麼很差麼？沒有！這兩個沒有任何問題，這兩個工做的都很好，很是優秀。使用者老是要求的多，老是但願

• 更易部署：無須受權完成任意登陸（ASO: Any Sign On）
• 更低資源：無需服務器端部署就能夠開啓工做
• 保障服務：基於固定的協議，同類型服務一致的數據結構
• 必須安全：沒有更，安全就是安全。不過很明顯絕對的安全是不存在的。
• 多方友好：協議細節將體現多方友好

OpenUser（之後簡稱OU） 試圖達到這些需求。

技術概述

• 通信平臺：經過客戶端進行。
• 可驗證ID：用戶登陸名也就是用戶登陸ID應該具備可驗證性。
• 加密登陸：包括登陸ID，密碼都要採用不可逆加密傳輸。
• 任意登陸：支持 OU 的站點經過簡化註冊或者第三方受權過程，讓用戶跟方便的登陸
• 站點驗證：因多方通信產生的須要驗證多方有效性。

通信平臺

通信可能涉及三方：終端用戶和兩個服務提供方。典型的客戶端就是瀏覽器。

可驗證ID

當用戶須要找回密碼的時候，用戶ID能夠提供可驗證性。最簡單的用戶ID就是 email

加密登陸

用戶輸入的是非加密信息，這些信息要經不可逆加密後才傳送給服務器端。 舉例採用MD5加密信息。 向服務器傳送：

md5(登陸ID)
md5(md5(密碼) + token)

token是服務器端在會話中分配給客戶端的一個字符串。此字符串保存在cookie中，隨提交發送至服務器。

服務器端驗證： 很明顯，服務器端須要保存的登陸ID和密碼都是是 md5 後的。而後經過 md5(登陸ID) 匹配到用戶數據，根據已保存的 md5(密碼) 和 cookie 中的 token 來驗證提交的 md5(md5(密碼) + token) 是否正確。 固然若是 token 不保存在 cookie 中，而做爲參數提交也不影響安全性。 現實實現中 token 能夠設計成帶過時驗證的，這個由實現決定。

任意登陸

任意登陸對應目前常見的第三方受權登陸。不一樣的是，因爲 OU 設計中服務器端保存的是不可逆加密的登陸ID和密碼。因此受權方能夠直接傳遞給服務器接受方，不可逆數據自己已經提供了安全保障。也許還有不可逆加密算法名稱，除了MD5外還有其餘算法。這種方式下，受權方已經再也不履行受權的角色，履行的是用戶註冊有效性無責任擔保角色。經過後用戶信息被直接轉移了。

站點驗證

• 由任意登陸形成的對受權方合法性驗證，這須要在服務端進行。(待完善)