什么是OpenID?OpenID是一種開(kāi)放、離散式的用于用戶(hù)數字標識的開(kāi)源框架。
請讓我們思考自己所擁有的在線(xiàn)賬號種類(lèi)：博客、wiki、
to-do list、
個(gè)人相冊。在網(wǎng)絡(luò )應用日益充斥的今天，這些個(gè)人在線(xiàn)賬號可謂不勝枚舉，而對賬號的需要也同樣無(wú)處不在，乃至當我們想在好友博客上進(jìn)行評論時(shí)都需要注冊成為
該博客系統的用戶(hù)。于是作為終端用戶(hù)，我們不得不在每個(gè)網(wǎng)站上設置賬號，并管理眾多的賬號。而采用OpenID技術(shù)的話(huà)，你就無(wú)須再管理這些相互獨立的帳
號，而是通過(guò)認證服務(wù)器管理自己唯一的身份標識。
OpenID常見(jiàn)的應用場(chǎng)景：某用戶(hù)試圖登錄一個(gè)外部網(wǎng)站。與提交用戶(hù)名和密碼的方式不同，他只提交了屬于自己的一個(gè)URL，例如：http://johnsmith.example.com/
這
個(gè)URL即指向了用戶(hù)的OpenID認證服務(wù)器，同時(shí)又是用戶(hù)的身份標識。因此外部網(wǎng)站使用此URL便可以找到用戶(hù)的認證服務(wù)器，并詢(xún)問(wèn)認證服務(wù)器：“該
用戶(hù)聲稱(chēng)他擁有此URL。而這個(gè)URL說(shuō)明了你負責認證工作，那么請告訴我，該用戶(hù)能否訪(fǎng)問(wèn)我的站點(diǎn)？”。認證服務(wù)器將提示用戶(hù)登入認證系統，并詢(xún)問(wèn)用戶(hù)
是否允許和外部網(wǎng)站進(jìn)行認證。如果用戶(hù)同意的話(huà)，那么認證服務(wù)器將通知外部網(wǎng)站——用戶(hù)已經(jīng)通過(guò)認證。在上面，我們通過(guò)擬人化的表達方式來(lái)形象生動(dòng)地詮釋
整個(gè)認證請求/回應過(guò)程。
用戶(hù)可以使用同一個(gè)URL用作在任何支持OpenID認證的外部網(wǎng)站中使用的標識。這正是OpenID與其它傳
統認證方式的最大不同。通過(guò)使用URL，可以使外部站點(diǎn)非常容易地獲取到負責認證工作的服務(wù)器位置。而只有認證服務(wù)器才需要輸入密碼來(lái)驗證用戶(hù)身份。其它
希望驗證用戶(hù)身份的站點(diǎn)都將詢(xún)問(wèn)用戶(hù)所注冊的認證服務(wù)器。如果你正在使用支持OpenID的門(mén)戶(hù)站點(diǎn)（比如AOL），那么你就可以使用現成的AOL即時(shí)消
息登錄賬號來(lái)登錄AOL站點(diǎn)，而無(wú)需另外注冊。因此，我們可以猜想Google和Yahoo也許已經(jīng)開(kāi)始著(zhù)手建造他們的OpenID服務(wù)。
你一定想知道OpenID是如何實(shí)現分散化服務(wù)的？由于用戶(hù)具有選擇OpenID服務(wù)提供者的權利，因此你會(huì )在最初選擇AOL作為OpenID提供者，而過(guò)一段時(shí)間后，可能覺(jué)得希望更換到另外一個(gè)OpenID提供者，此時(shí)你所需要做的就是修改以下的HTML標簽：
<link rel="openid.server" >
保存這些link元數據的最常見(jiàn)位置就是個(gè)人站點(diǎn)（比如博客）的根頁(yè)面。
如何使用OpenID?OpenID
絕妙地解決了多個(gè)賬號同步問(wèn)題，但并不僅僅如此。例如，你可以利用它建立跨應用、跨域的單點(diǎn)登錄（Single
sign-on）。如果你使用同一個(gè)OpenID登入了博客和個(gè)人相冊，那么你只需要在登錄過(guò)程中進(jìn)行一次認證。對于在此之后的每個(gè)需要登錄的應用（在同
一個(gè)session周期）只需提供OpenID，而不是傳統的用戶(hù)名和密碼。
大多數OpenID提供者也提供了支持多個(gè)配置的功能。這樣
你就可以使用“Bob Smith”登錄博客，而使用“Robert J
Smith”登錄企業(yè)wiki。隨著(zhù)OpenID提供者的日益成熟和OpenID功能上的提升，我們不久就會(huì )使用對來(lái)自伙伴公司OpenID認證服務(wù)器主
機名的用戶(hù)進(jìn)行認證的服務(wù)。
哪些網(wǎng)站支持OpenID?OpenID技術(shù)出現不久，便獲得了在眾多公共消費站點(diǎn)的熱捧：
Digg、
Six Apart、
Zoomr和
AOL。
其中AOL為老用戶(hù)提供了OpenID支持，使得六千五百萬(wàn)的登錄用戶(hù)在一日之內就全部能夠使用OpenID。目前已經(jīng)具有超過(guò)九千五百萬(wàn)的用戶(hù)能夠使用
OpenID登錄系統，并且每天都有25至50個(gè)站點(diǎn)加入到支持OpenID規范的隊伍中。另外，OpenID增加了對Firefox3和微軟
Windows Vista的支持。
下面是實(shí)現了OpenID代碼庫的語(yǔ)言列表：
? C#
? C++
? Java
? Perl
? Python
? Ruby
? PHP
? Coldfusion
OpenID社區維護了這些代碼庫的清單：
http://openid.net/wiki/index.php/Libraries。在本文的后面，我們將討論到OpenID的Java實(shí)現：OpenID4Java(
http://www.openid4java.org)。
OpenID協(xié)議綜述OpenID協(xié)議非常易于擴展，下面的圖表展示了
OpenID2.0草案的基本工作流程。它展示了在終端用戶(hù)、Relying Party站點(diǎn)（一個(gè)示例站點(diǎn)）和OpenID服務(wù)提供者之間的交互過(guò)程（最常見(jiàn)的認證流程）。
用戶(hù)登入外部站點(diǎn)的過(guò)程主要分為以下七個(gè)步驟：
1. Relying Party站點(diǎn)請求用戶(hù)標識此步驟非常簡(jiǎn)單：用戶(hù)提供一個(gè)字符串（以URL或者XRI格式）給外部站點(diǎn)，使后者能夠識別用戶(hù)。
1.
外部站點(diǎn)請求用戶(hù)發(fā)送標識。通常使用帶有Open圖標的文本輸入框、用于提交信息的按鈕組成的form來(lái)完成此功能。為了方便起見(jiàn)，文本輸入框的name
屬性應為openid_identifier，這樣以便瀏覽器自動(dòng)將其識別為一個(gè)OpenID登錄form。
2.用戶(hù)輸入標識，標識可能采用下面的形式：
? URI/URL (通過(guò)http或者https)
?
XRI。XRI是一種廣義的、分散式的URI。它能用于任何使用URI的地方。XRI主要采用以下形式：xri://authority/path?query#fragment。了解更多關(guān)于XRI的信息請看：
XRI語(yǔ)法規范。
用戶(hù)標識類(lèi)似這個(gè)樣子：http://myname.myhost.com/。外部站點(diǎn)經(jīng)常將OpenID logo放置到其登錄form上，這樣可以使你很快地辨別出是否使用OpenID。
用戶(hù)在點(diǎn)擊位于外部站點(diǎn)登錄頁(yè)面上的“Login”按鈕后便啟動(dòng)了認證過(guò)程。
2.“標準化”: Relying Party站點(diǎn)整理用戶(hù)標識用戶(hù)輸入了標識后，此標識便由外部站點(diǎn)進(jìn)行整理（標準化）。由于標識可能使用XRI或者URI格式，因此整理的過(guò)程非常復雜：
1.如果標識以xri://、xri://$ip或者xri://$dns*開(kāi)頭，那么我們要去掉這些頭部標記。
2.
如果余下字符串中的第一個(gè)字符是XRI的全局上下文符號（=、@、+、 $、!），那么此字符串為標準的XRI標識。否則，將被視為HTTP
URL（如果http/https前綴沒(méi)有定義，我們需要為其添加上http://）。當然，URL必須遵守URL命名規范。最終獲得的URL就是一個(gè)標
準的URL標識。
下面是一些示例：
下面的流程圖描繪了標準化處理過(guò)程：
3.“發(fā)現”: Relying Party站點(diǎn)查詢(xún)與OpenID服務(wù)器進(jìn)行通訊的方式外部站點(diǎn)使用標準化的標識來(lái)查詢(xún)用于發(fā)起請求所必須的信息。對于“發(fā)現”階段來(lái)講，其使用的解析協(xié)議和獲取的結果文檔都取決于在標準化階段決定的標識類(lèi)型。這正是OpenID2.0規范的特殊之處。
快速參考: ? XRI 解析:類(lèi)似通過(guò)UDP將主機名解析為IP的DNS協(xié)議；它將XRI轉換為XRDS。其目的是提供一種將厚重、通用的XRI格式轉換為真實(shí)可用的描述符。
? YADIS協(xié)議:將URL連接到XRDS上。這是一種非常簡(jiǎn)單的協(xié)議，它將當前的HTTP或者HTTPS URL直接指向XRDS。
?
XRDS：一種基于XML的XRI資源描述符。它被設計用來(lái)提供關(guān)于XRI的可用的、描述性信息。在OpenID應用場(chǎng)合中，XRDS用來(lái)描述
OpenID服務(wù)器，并且使用“priority”參數標識了用戶(hù)對服務(wù)器的優(yōu)選順序。在下面的示例中，http:
//www.livejournal.com/users/frank具有最高的優(yōu)先權（最低的數值）：
<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"
xmlns:openid="http://openid.net/xmlns/1.0">
<XRD>
<Service priority="50">
<Type>http://openid.net/signon/1.0</Type>
<URI>http://www.myopenid.com/server</URI>
<openid:Delegate>http://smoker.myopenid.com/</openid:Delegate>
</Service>
<Service priority="10">
<Type>http://openid.net/signon/1.0</Type>
<URI>http://www.livejournal.com/openid/server.bml</URI> <openid:Delegate>http://www.livejournal.com/users/frank/</openid:Delegate>
</Service>
<Service priority="20">
<Type>http://lid.netmesh.org/sso/2.0</Type>
<URI>http://mylid.net/liddemouser</URI>
</Service>
</XRD>
</xrds:XRDS>
? 使用HTML代碼。在HTML的<head>部分必須提供以下標簽：
<link rel="openid2.provider" />
可選的，如果用戶(hù)使用委派（delegation）（就是用戶(hù)宣稱(chēng)擁有一個(gè)不存在于該OpenID服務(wù)器上的本地標識），則需要使用下面的標簽：
<link rel="openid2.local_id" />
例如，某人正在使用openidprovider.com這個(gè)OpenID服務(wù)器來(lái)驗證他在另一個(gè)OpenID服務(wù)器usersite.com上的身份，那么其本地標識將使用類(lèi)似user.openidprovider.com的形式。
這個(gè)“發(fā)現”的過(guò)程允許外部站點(diǎn)知道兩件事，其中一件是外部站點(diǎn)如何與OpenID服務(wù)器進(jìn)行通訊：
1.OpenID提供者端點(diǎn)URL：OpenID提供者的最終URL（服務(wù)器URL）。
2.認證協(xié)議版本: OpenID認證使用的協(xié)議版本。
作為可選的，如果用戶(hù)使用委派，那么外部站點(diǎn)將需要知道：
1.用戶(hù)宣稱(chēng)的標識：此標識為用戶(hù)宣稱(chēng)屬于自己的。它是在登錄過(guò)程中用戶(hù)提供過(guò)的標識。
2.本地標識（OP-Local Identifier）:用戶(hù)在其OpenID服務(wù)器上擁有的本地標識。
例
如，用戶(hù)使用http://www.example.com/作為其標識，但外部網(wǎng)站實(shí)際上通過(guò)https:
//www.exampleprovider.com/endpoint/這個(gè)OpenID服務(wù)器來(lái)驗證用戶(hù)標識https:
//exampleuser.exampleprovider.com/。那么在對http://www.example.com/執行發(fā)現的過(guò)程中，我
們需要在XRDS文檔的最后一個(gè)XRD成員中提供下面的XML片段
<Service xmlns="xri://$xrd*($v*2.0)">
<Type>http://specs.openid.net/auth/2.0/signon</Type>
<URI>https://www.exampleprovider.com/endpoint/</URI>
<LocalID>https://exampleuser.exampleprovider.com/</LocalID>
</Service>
4. Relying Party站點(diǎn)建立與OpenID服務(wù)器之間的關(guān)聯(lián)(可選)通過(guò)在外部站點(diǎn)和OpenID服務(wù)器之間的關(guān)聯(lián)（association），我們可以建立一種在兩者之間共享的加密通道，它可以用來(lái)驗證后續的協(xié)議信息并降低通訊回合數。在OpenID規范中對于實(shí)際創(chuàng )建關(guān)聯(lián)的過(guò)程進(jìn)行了詳盡的描述。簡(jiǎn)單來(lái)講就是使用了一種
Diffie-Hellman密鑰交換算法來(lái)生成共享密鑰。此密鑰用于對信息進(jìn)行簽名。
這
樣使得外部站點(diǎn)和OpenID服務(wù)器之間能夠安全地通訊。這里指的“安全性”是通過(guò)傳輸層（使用SSL）或者通過(guò)應用層的HMAC
SHA1或者HMAC
SHA256算法實(shí)現的。關(guān)聯(lián)請求的成果就是assoc_handle（關(guān)聯(lián)權柄），外部站點(diǎn)和OpenID服務(wù)器將在本次關(guān)聯(lián)的后繼活動(dòng)中將它作為對消
息進(jìn)行加密的密鑰。
關(guān)聯(lián)階段被標為“可選的”，這是因為OpenID協(xié)議還允許外部站點(diǎn)直接請求認證（不作關(guān)聯(lián)）、并且接著(zhù)請求對認證信
息進(jìn)行驗證。這樣外部站點(diǎn)可以不保有關(guān)聯(lián)權柄信息，以實(shí)現無(wú)狀態(tài)通訊。而這種方式被推薦用于執行與OpenID服務(wù)器之間的相關(guān)通訊，但如果不能使用此方
式的話(huà)，就必須創(chuàng )建上面講的關(guān)聯(lián)方式。
5. Relying Party站點(diǎn)請求認證我們通過(guò)使用重定向頁(yè)面可以建立認證請求。請查看下表中的重要參數值，詳細信息請參考OpenID相關(guān)信息格式文檔：
請注意：外部站點(diǎn)并沒(méi)有直接發(fā)送HTTP請求到OpenID服務(wù)器，而是重定向到OpenID服務(wù)器頁(yè)面。由于這樣使得OpenID服務(wù)器能夠從用戶(hù)瀏覽器中讀取cookie而沒(méi)有將任何認證細節泄露給外部站點(diǎn)，因此這個(gè)過(guò)程是安全的。
6. OpenID服務(wù)器回應認證請求在接收到OpenID認證請求后，OpenID服務(wù)器必須決定允許還是拒絕此用戶(hù)的認證。這將由用戶(hù)從前是否在OpenID服務(wù)器上認證過(guò)決定。
請注意：OpenID服務(wù)器在接收認證請求信息時(shí)是具有控制權的。這意味著(zhù)它不但能夠異步地回應認證請求信息，并在它回應認證請求之前與用戶(hù)進(jìn)行一系列的交互。大多數認證服務(wù)器都提供給用戶(hù)一個(gè)頁(yè)面使其能夠選擇允許或者拒絕來(lái)自外部站點(diǎn)的認證請求。
一旦OpenID服務(wù)器已經(jīng)回應了認證請求，那么它將創(chuàng )建一個(gè)如下描述的認證回應信息，低層信息細節請閱讀OpenID協(xié)議文檔：
此回應通過(guò)將用戶(hù)重定向到外部站點(diǎn)的方式發(fā)送，以確保外部站點(diǎn)和OpenID服務(wù)器之間在認證請求/回應過(guò)程中沒(méi)有直接通訊。
7. 驗證間接回應協(xié)議的最后一步是外部站點(diǎn)驗證這個(gè)發(fā)自OpenID服務(wù)器的間接認證回應信息。
當外部站點(diǎn)接收到回應時(shí)，它必須在接受其內容之前進(jìn)行下面的驗證：
? “openid.return_to”的參數值是否匹配當前請求的URL。這確保OpenID服務(wù)器重定向用戶(hù)、發(fā)送回應信息到正確的URL。
? 被發(fā)現的信息是否與回應信息相匹配。
? 具有相同參數值的“openid.response_nonce”表示OpenID服務(wù)器遭到了重放攻擊(reply attacks)。
? 在回應信息中的簽名是否有效、要求的簽名域是否都被簽名。這保證認證信息沒(méi)有被篡改過(guò)。
協(xié)議擴展OpenID協(xié)議提供了一個(gè)基本的認證機制。目前還有基于OpenID的其它可用協(xié)議：
?
Attribute Exchange：OpenID屬性交換是一種用于在端點(diǎn)之間交換標識信息OpenID服務(wù)擴展。其提供了對標識信息的接收和存儲。
?
Simple Registration：這是OpenID認證協(xié)議的擴展，它允許非常輕量級的配置交換。主要用于在終端用戶(hù)使用web服務(wù)注冊新賬號時(shí)傳送八種常用的請求信息。
使用OpenID4Java實(shí)現OpenID協(xié)議OpenID4Java是對OpenID1.1和2.0規范的實(shí)現，目前它通過(guò)
code.google.com系統進(jìn)行維護。此項目初始代碼是由Sxip捐獻出來(lái)的，而后Atlassian等公司參與進(jìn)來(lái)，并為實(shí)現支持2.0規范（屬性交換規范）的API貢獻了大量的工作。
在使用OpenID4Java之前，你需要完成以下工作：
? 下載OpenID4Java代碼庫，并將其安裝到你的項目中。
? 修改你的認證提示，使其詢(xún)問(wèn)用戶(hù)的OpenID標識，而不是從前的用戶(hù)名和密碼。
? 創(chuàng )建針對用戶(hù)標識的認證請求，并將用戶(hù)重定向到他們的OpenID服務(wù)器。
? 在返回URL中接收OpenID提供者的認證回應并進(jìn)行驗證。
這樣，你的web應用就會(huì )像在上面協(xié)議綜述中的流程圖所展示的“Relying Party”那樣工作。
第一步是創(chuàng )建消費者對象，它將向認證服務(wù)器發(fā)出認證請求。這里我們將消費者對象視為一個(gè)貫穿應用的個(gè)體，以使相關(guān)的關(guān)聯(lián)密鑰能夠保存在同一位置。因為當面臨多個(gè)認證請求時(shí)，在不同的請求之間保存密鑰將在兩個(gè)端點(diǎn)（請求和回應端點(diǎn)）間引起下幅度的性能下降。
Sample Consumer代碼片段：
/**
* Sample Consumer (Relying Party) implementation.
*/
public class SampleConsumer
{
public ConsumerManager manager;
public SampleConsumer() throws ConsumerException
{
// instantiate a ConsumerManager object
manager = new ConsumerManager();
}
...
}
一旦用戶(hù)提供了OpenID URL，你就需要獲取OpenID認證服務(wù)器的端點(diǎn)URL，發(fā)送請求到此URL。而OpenID認證服務(wù)器的端點(diǎn)被確定后，你還要創(chuàng )建一個(gè)和服務(wù)器關(guān)聯(lián)的共享密鑰。
// discover the OpenID authentication server‘s endpoint URL
List discoveries = manager.discover(userSuppliedOpenID);
// attempt to associate with the OpenID provider
// and retrieve one service endpoint for authentication
DiscoveryInformation discovered = manager.associate(discoveries);
// store the discovery information in the user‘s session for later use
session.setAttribute("discovered", discovered);
以上的調用將完成：
? 下載OpenID提供者列表（一般只有一個(gè)提供者）。返回結果將按照用戶(hù)指定的優(yōu)選順序排列。
? 通過(guò)關(guān)聯(lián)獲取和OpenID提供者之間的共享密鑰。
? 將關(guān)聯(lián)（發(fā)現信息）保存，以備之后的使用。
我們現在需要將用戶(hù)重定向到他們的OpenID提供者頁(yè)面，并告訴OpenID提供者外部站點(diǎn)的地址（返回URL，這里就是你的站點(diǎn)），以使OpenID提供者知道在執行完認證后將用戶(hù)發(fā)送到哪里。
// define the return path
String returnURL = "http://company.com/openidresponse.jsp";
// generate an AuthRequest message to be sent to the OpenID provider
AuthRequest authReq = manager.authenticate(discovered, returnURL);
// redirect the user to their provider for authentication
httpResp.sendRedirect(authReq.getDestinationUrl(true));
上
面的代碼將用戶(hù)重定向到他們的OpenID提供者，在那里用戶(hù)將被詢(xún)問(wèn)是否同意和你的站點(diǎn)進(jìn)行認證。（請注意：無(wú)論用戶(hù)同意“臨時(shí)”授權給你的web應
用、還是“總是”或者“不”授權，OpenID提供者都將保存此首選標識）。當用戶(hù)再次訪(fǎng)問(wèn)你的web應用時(shí)，如果用戶(hù)已經(jīng)被OpenID提供者認證過(guò)并
且在首次認證時(shí)選擇了“總是”，那么此用戶(hù)將可以訪(fǎng)問(wèn)你的web應用，而無(wú)需再次認證。
在認證用戶(hù)之后，OpenID提供者將用戶(hù)重定向到外部站點(diǎn)（由返回URL定義的web應用），并發(fā)送認證回應信息給你的web應用，而你的web應用將需要接收此回應。你可以顯示錯誤信息或者將用戶(hù)發(fā)送到“成功”頁(yè)面，這完全取決于你的工作流。
這是處理來(lái)自OpenID提供者認證信息的最簡(jiǎn)單過(guò)程：
// extract the parameters from the authentication response
// (which comes in as a HTTP request from the OpenID provider)
ParameterList openidResp = new ParameterList(request.getParameterMap());
// retrieve the previously stored discovery information
DiscoveryInformation discovered = (DiscoveryInformation) session.getAttribute("discovered");
// extract the receiving URL from the HTTP request
StringBuffer receivingURL = request.getRequestURL();
String queryString = request.getQueryString();
if (queryString != null && queryString.length() > 0)
receivingURL.append("?").append(request.getQueryString());
// verify the response
VerificationResult verification = manager.verify(receivingURL.toString(), openidResp, discovered);
// examine the verification result and extract the verified identifier
Identifier verified = verification.getVerifiedId();
if (verified != null)
// success, use the verified identifier to identify the user
else
// OpenID authentication failed
查看完整的Sample Consumer代碼：
http://code.google.com/p/openid4java/wiki/SampleConsumer結論OpenID是通過(guò)標準化認證方式由互聯(lián)網(wǎng)社區催生出來(lái)的綜合效應。它完成了和SAML這些現存協(xié)議同樣的事情，但它卻易于安裝、部署和維護。任何具備基本編程技能的人都能夠在其現有或者新建的網(wǎng)站上部署OpenID技術(shù)。
OpenID已經(jīng)獲得愈加廣泛的使用。我們有理由相信，在不久之后的公司之間、像Google和Yahoo這樣的門(mén)戶(hù)站點(diǎn)之間都將支持此技術(shù)，OpenID技術(shù)將隨著(zhù)互聯(lián)網(wǎng)社區的發(fā)展而成為網(wǎng)站之間通用的主流認證方法。
關(guān)于OpenID技術(shù)的更多信息，請訪(fǎng)問(wèn)：
http://openid.net/原文（《Using OpenID》）作者簡(jiǎn)介Justen Stepka是
Atlassian的Crowd單點(diǎn)登錄安全系統的項目管理者，同時(shí)也是OpenID4Java項目的提交者（committer）。Crowd團隊目前正在開(kāi)發(fā)實(shí)現OpenID2.0規范的服務(wù)站點(diǎn)。Justen從前是
Authentisoft的CEO，該公司于2006年被Atlassian收購。
Shihab Hamid是在A(yíng)tlassian工作的工程師，他主要負責用Crowd產(chǎn)品在OpenID集成方面的設計和開(kāi)發(fā)。同時(shí)也是OpenID4Java項目的提交者。
