OpenID

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
OpenID的logo

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）

最終用戶用以標識其身份的URL或XRI。

身份提供者（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提供商

運作方式

法律問題

參考資料

  1. ^ 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）. 
  2. ^ 存档副本. [2008-12-14]. （原始內容存檔於2009-01-25）. 
  3. ^ 存档副本. [2015-01-29]. （原始內容存檔於2015-01-18）. 
  4. ^ Wang Jing. [2014-11-10]. （原始內容存檔於2014-11-08）. 
  5. ^ Serious security flaw in OAuth, OpenID discovered. CNET. 2 May 2014 [10 November 2014]. （原始內容存檔於2015-11-02）. 
  6. ^ Covert Redirect. Tetraph. 1 May 2014 [10 November 2014]. （原始內容存檔於2016-03-10）. 
  7. ^ 两款互联网登录系统曝出重大漏洞 短期内或无法修复. 鳳凰網. 5月 03 2014. [2014-11-10]. （原始內容存檔於2014-11-08）. 
  8. ^ Covert Redirect. OpenID. 15 May 2014 [10 November 2014]. （原始內容存檔於2014-10-20）. 
  9. ^ Oauth2.0协议曝漏洞 大量社交网隐私或遭泄露. 人民網. 5月 04 2014. [2014-11-10]. （原始內容存檔於2014-11-08）. 

外部連結

取自「https://zh.wikipedia.org/w/index.php?title=OpenID&oldid=79800129」