OpenID
 | 此條目需要補充更多來源。 (2023年11月19日) |
OpenID是一個去中心化的網上身份認證系統。對於支援OpenID的網站，用戶不需要記住像用戶名和密碼這樣的傳統驗證標記。取而代之的是，他們只需要預先在一個作為OpenID身份提供者（identity provider, IdP）的網站上註冊。OpenID是去中心化的，任何網站都可以使用OpenID來作為用戶登入的一種方式，任何網站也都可以作為OpenID身份提供者。OpenID既解決了問題而又不需要依賴於中心性的網站來確認數碼身份。
歷史
[編輯]OpenID最初由LiveJournal的Brad Fitzpatrick開發，後來加入了Light-Weight Identity，Yadis，Sxip DIX protocol和XRI/i-names。未來的OpenID規範正在由OpenID.net開發，很多技術公司、服務公司和開源開發者[哪個／哪些？]都參與其中。
為了推動OpenID的應用，2006年8月，一些公司[哪個／哪些？]贊助設立了OpenID獎勵計劃，對前10位滿足要求的軟件專案各獎勵5000美元。
2007年12月5日，OpenID驗證規範9.0和屬性交換規範9.0發佈。
使用OpenID
[編輯]OpenID相關基本術語：
終端使用者（End User）
- 想要向某個網站表明身份的人。
標識（Identifier）
身份提供者（Identity Provider, IdP）
- 提供OpenID URL或XRI註冊和驗證服務的服務提供者。
依賴方（Relying Party, RP）
- 想要對終端使用者的標識進行驗證的網站。
登入
[編輯]一個想要為其訪問者提供OpenID登入網站，比如example.com，需要在頁面的某個地方放置一個登入表單。與提示用戶輸入用戶名和密碼的傳統登入表單不同的是，這種表單只有一個輸入框：OpenID標識。網站可以選擇在這個輸入框旁顯示一個小的OpenID圖示。這個表單與OpenID客戶端庫的實現相連接。
假設用戶Alice在身份提供者openid-provider.org處註冊了一個OpenID標識：alice.openid-provider.org。如果Alice想使用這個標識來登入example.com，她只需要到example.com去將alice.openid-provider.org填入OpenID登入表單。
如果標識是一個URL，依賴方example.com做的第一件事情是將這個URL轉換為典型格式：http://alice.openid-provider.org/。在OpenID 1.0中，依賴方接着請求該URL對應的網頁，然後通過一個HTML連結tag發現提供者伺服器，比如http://openid-provider.org/openid-auth.php。同時也確定是否應該使用授權身份（delegated identity）。從OpenID 2.0開始，依賴方請求的是XRDS文件（也稱為Yadis文件），使用內容類型application/xrds+xml。這種類型在URL中可能存在，而在XRI中總是存在。
依賴方可以通過兩種模式來與身份提供者通訊：
checkid_immediate：兩個伺服器間的所有通訊都在後台進行，不提示用戶。checkid_setup：用戶使用訪問依賴方站點的同一個瀏覽器窗口與身份提供者伺服器互動。
第二種模式更加常用。而且，如果操作不能夠自動進行的話，checkid_immediate模式會轉換為checkid_setup模式。
首先，依賴方與身份提供者建立一個「共用秘密」——一個聯絡控制代碼，然後依賴方儲存它。如果使用checkid_setup模式，依賴方將用戶的網頁瀏覽器重新導向到提供者。在這個例子裏，Alice的瀏覽器被重新導向到openid-provider.org，這樣Alice能夠向提供者驗證自己。
驗證的方法可能不同，但典型地，OpenID提供者要求提供密碼（然後可能使用cookies儲存用戶對談，就像很多基於密碼驗證的網站的做法一樣）。如果Alice當前沒有登入到openid-provider.org，她可能被提示輸入密碼，然後被問到是否信任依賴方頁面——如http://example.com/openid-return.php，這個頁面被example.com指定為用戶驗證完成後返回的頁面——取得她的身份資訊。如果她給出肯定回答，OpenID驗證被認為是成功的，瀏覽器被重新導向到被信任的返回頁面。如果Alice給出否定回答，瀏覽器仍然會被重新導向，然而，依賴方被告知它的請求被拒絕，所以example.com也依此拒絕Alice的登入。
但是，登入的過程還沒有結束，因為在這個階段，example.com不能夠確定收到的資訊是否來自於openid-provider.org。如果他們之前建立了「共用秘密」，依賴方就可以用它來驗證收到的資訊。這樣一個依賴方被稱為是stateful的，因為它儲存了對談間的「共用秘密」。作為對比，stateless的驗證方必須再作一次背景請求（check_authentication）來確保數據的確來自openid-provider.org。
Alice的標識被驗證之後，她被看作以alice.openid-provider.org登入到example.com。接着，這個站點可以儲存這次對談，或者，如果這是她的第一次登入，提示她輸入一些專門針對example.com的資訊，以完成註冊。
OpenID不提供它自己的驗證方式，但是如果身份提供者使用強驗證，OpenID可被用於安全事務，比如銀行和電子商務。
推廣
[編輯]OpenID正在被越來越多的大網站採用。Yahoo!已經支援OpenID。所有有Yahoo帳戶的用戶可以通過OpenID directed identity方式登入支援OpenID信賴方網站。[1] [2]
Google 曾經支援OpenID 2.0，不過自 2015 年 4 月 20 日起，Google 帳戶將不再使用 OpenID，轉而使用OpenID Connect。[3]
Orange、AOL與Yahoo!都已經支援OpenID。AOL提供每個AOL或AIM的用戶一組OpenID Identity，目前還在測試階段，為openid.aol.com/username。
目前使用OpenID代替一般帳號密碼的網站包括了 著名的開源社區SourceForge、LiveJournal、Zooomr、Wikitravel、ma.gnolia.com、claimid.com以及Jyte。
在openid.net上有一份公開的伺服器列表，可以讓一般人申請OpenID Identity。
安全
[編輯]隱蔽重新導向漏洞(Covert Redirect)
[編輯]2014年5月，新加坡南洋理工大學一位名叫王晶（Wang Jing）的物理和數學科學學院博士生[4]，發現了OAuth和OpenID開源登入工具的"隱蔽重新導向漏洞"[5][6][7]。
其實漏洞不是出現在OpenID這個協定本身，這個協定本身是沒有問題的，之所以存在問題是因為各個廠商沒有嚴格參照官方文件，只是實現了簡版。問題的原因在於OpenID的提供方提供OpenID授權過程中沒有對回呼的URL進行校驗，從而導致可以被賦值為非原定的回呼URL[8][9]。
中文OpenID提供商
[編輯]- www.CloudID.cn[永久失效連結] - 支援動態口令，免費
- VIeID.com
- openid.org.cn（頁面存檔備份，存於互聯網檔案館） - 多國語言，免費 - OpenID格式：http://用户名.openid.org.cn/
- 87id（頁面存檔備份，存於互聯網檔案館） - 中英文，免費，支援IPv6 - OpenID格式：http://用户名.87id.com/
- openid.35.com - 中英文，免費 - OpenID格式：http://openid.35.com/users/ 用户名/
- login.comrite.com（頁面存檔備份，存於互聯網檔案館） - 中英文，免費 - OpenID格式：http://login.comrite.com/ 用户名
- myID.tw（頁面存檔備份，存於互聯網檔案館） - 中文，免費 - OpenID格式：http://用户名.myid.tw/
運作方式
[編輯]![[icon]](/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | 此章節尚無任何內容，需要擴充。 (2010年5月4日) |
法律問題
[編輯]參考資料
[編輯]- ^ Yahoo! Announces Support for OpenID; Users Able to Access Multiple Internet Sites with Their Yahoo! ID. Yahoo!. 2008-01-17 [2008-03-20]. （原始內容存檔於2008-03-04）.
- ^ 存档副本. [2008-12-14]. （原始內容存檔於2009-01-25）.
- ^ 存档副本. [2015-01-29]. （原始內容存檔於2015-01-18）.
- ^ Wang Jing. [2014-11-10]. （原始內容存檔於2014-11-08）.
- ^ Serious security flaw in OAuth, OpenID discovered. CNET. 2 May 2014 [10 November 2014]. （原始內容存檔於2015-11-02）.
- ^ Covert Redirect. Tetraph. 1 May 2014 [10 November 2014]. （原始內容存檔於2016-03-10）.
- ^ 两款互联网登录系统曝出重大漏洞 短期内或无法修复. 鳳凰網. 5月 03 2014. [2014-11-10]. （原始內容存檔於2014-11-08）.
- ^ Covert Redirect. OpenID. 15 May 2014 [10 November 2014]. （原始內容存檔於2014-10-20）.
- ^ Oauth2.0协议曝漏洞 大量社交网隐私或遭泄露. 人民網. 5月 04 2014. [2014-11-10]. （原始內容存檔於2014-11-08）.
外部連結
[編輯]- 官方網站
（英文）
