|
OpenID 是一個去中心化的單一登陸身份系統。對於支持OpenID的網站,用戶不需要記住像用戶名和密碼這樣的傳統驗證標記。取而代之的是,他們只需要預先在一個作為OpenID身份提供者(identity provider,IdP)的網站上註冊。OpenID是去中心化的,任何網站都可以使用OpenID來作為用戶登陸的一種方式,任何網站也都可以作為OpenID身份提供者。OpenID既解決了問題而又不需要依賴於中心性的網站來確認數字身份。
OpenID正在被越來越多的大網站採用,比如作為身份提供者的AOL和Orange。另外,Firefox 3將集成OpenID支持作為高優先順序處理;OpenID可以和.NET Framework的Windows CardSpace一起使用。
一個想要為其訪問者提供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/。在OpenID1.0中,依賴方接著請求該URL對應的網頁,然後通過一個HTML連結tag發現提供者伺服器,比如http://openid-provider.org/openid-auth.php。同時也確定是否應該使用授權身份(delegatedidentity)。從OpenID2.0開始,依賴方請求的是XRDS文檔(也稱為Yadis文檔),使用內容類型application/xrds+xml。這種類型在URL中可能存在,而在XRI中總是存在。
依賴方可以通過兩種模式來與身份提供者通信:
- checkid_immediat: 兩個伺服器間的所有通信都在後臺進行,不提示用戶。
- checkid_setup: 用戶使用訪問依賴方站點的同一個瀏覽器窗口與身份提供者伺服器交互。
第二種模式更加常用。而且,如果操作不能夠自動進行的話,checkid_immediate模式會轉換為checkid_setup模式。
首先,依賴方與身份提供者建立一個「共享秘密」 ——一個聯繫句柄,然後依賴方存儲它。如果使用checkid_setup模式,依賴方將用戶的網頁瀏覽器重定向到提供者。在這個例子里,Alice的瀏覽器被重定向到openid-provider.org,這樣Alice能夠向提供者驗證自己。
驗證的方法可能不同,但典型地,OpenI提供者要求提供密碼(然後可能使用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可被用於安全事務,比如銀行和電子商務。
|
|