于OPENID的单点登陆协议

因为经常看到有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技术博客