因爲經常看到有OpenId的吹捧者，所以本來希望寫一個OpenId的BLOG，引起大家的注意，然後從他們哪兒獲得一些關於OpenId詳細協議的資料，可惜失算了。
不得以，今天早上，花了一些時間，在詞典的幫助下用我蹩腳的英語翻譯了一下OpenId的協議。終於搞明白了OpenId的加密驗證模式。
最關鍵的是第三步和第七步。這兩步由應用服務器任選其一，他們都是應用服務器直接與身份驗證服務器交互，第三步是獲得並保存一個密匙，用於嚴整用戶所傳遞的數據是否合法。第七步則是直接把接受的信息交個身份驗證服務器，然後由身份驗證服務器來驗證這個信息是否合法。
這樣以來，我前邊所講的哪個HACK的模式就的確是行不通的了。
———以下是我翻譯的全文———
一個帶圖片說明的OpenId協議介紹
A description of the OpenID protocol with diagrams.
1: User submits Identity URL
1：用戶提交身份地址
The consumer uses a form with GET or POST to allow the user to enter their OpenID url.
應用服務器通過GET或者POST方法獲得用戶提交他們的OpenId地址(身份地址)
2: Consumer fetches Identity URL
2:應用服務器取得身份驗證服務器
The consumer parses the HTML content and looks for a tag:
<LINK REL='openid.server' HREF=(the server)>
應用服務器解吸用戶提交的地址的數據中的HTML標籤:<link rel=’openid.server’ href=’the server’>（其中the server 就是身份驗證服務器）
3: Consumer associates with server (option 1)
3:應用服務器與身份驗證服務器交互（選項1）
In order to communicate securely with the server, the consumer gets an association with the server discovered in step 2, using an existing association if it is available, otherwise visiting the server and using Diffie Hellman to negotiate a shared secret with which to sign communication. A consumer unable to store state uses "dumb mode" which does not perform this step, and instead uses step 7.
爲了能夠與身份驗證服務器安全的通信，應用服務器需要向（從第2步獲取的）身份驗證服務器請求一個協議。如果有現成的可以使用的協議，則用現有的協議，否則，通過Diffie Hellman的方法獲得一個共享密匙，靜默模式（dumb mode）下的應用服務器不需要這一步，而是使用第7步的操作。
4: Consumer redirects the user to the server
4：應用服務器將用戶重定向到身份驗證服務器
The OpenID server URL accepts a query, containing all the information the server needs to check the user's identity and redirect the user back to the consumer. The server checks the authentication of the user. If the user is signed in (has an auth cookie) and has already authorized sending their identity to the consumer, step 5 may be skipped.
OpenId服務器接受一個包含所有應用服務器需要用來驗證用戶的信息，如果用戶已經登陸（有COOKIE）並且他已經同意發送他的身份信息給應用服務器的話，第5步可以跳過。
5: User Authenticates to server
5:用戶鑑別是否是自己訪問的服務
The user authenticates to the server with a cookie or a username and password, and the server asks the user for permission to send their identity information to the consumer.
通過COOKIE或者用戶名+密碼驗證當前用戶是否登陸，並且詢問當前用戶是否允許應用服務器獲得自己的身份信息。
6: Server redirects the user back to the consumer
6: 身份驗證服務器重定向用戶到應用服務器
The consumer parses the servers response (which is appended to the return-to URL the consumer sent) and verifies it using the association, or in the case of dumb mode proceeds to step 7.
應用服務器使用獲得的身份驗證服務器的協議，校驗並解析所返回的數據。如果在靜默模式（dumb mode）下，繼續第7步。
7: Consumer verifies the response with the server (option 2)
7:應用服務器通過身份驗證服務器校驗接收到的信息（選項2）
Communicating directly with the server, the dumb mode consumer checks the response received via the User Agent in the redirect.
應用服務器直接連接身份驗證服務器校驗接受到的信息，在靜默模式下的應用服務器使用重定向的方法通過身份地址(User Agent)覈對接受到的信息。
本文出自 “網絡新勢力” 博客，轉載請與作者聯繫！
本文出自 51CTO.COM技術博客