wiki百科:  http://zh.wikipedia.org/wiki/OpenID

官网: http://openid.net/  规范:http://openid.net/developers/specs/

这篇文章较适入门：  http://www.theserverside.com/news/1364125/Using-OpenID 作者也是open4javba的作者。

使用open4java,wicket

上 http://www.ibm.com/developerworks/cn/java/j-openid/

下  http://www.ibm.com/developerworks/cn/java/j-openid2/index.html?ca=drs-cn-0427

讲得最明白的还是google: http://code.google.com/intl/zh-CN/apis/accounts/docs/OpenID.html

http://www.seven2.com.cn/archives/786/  Google OAUTH + OpenID 解决方案

open4java 用起来总是报错，说什么xml解析错误，查了半天原来是xml解析包冲突,遇到这种情况要检查一下别的引用是否有冲突的xml解析包。

使用0.9.6 maven一直下载不下来改用0.9.5就可以了。

运行simple-openid这个示例只需要这样的pom:

<project xmlns="http://maven.apache.org/POM/4.0.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>test</groupId>
	<artifactId>test</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<dependencies>		
		<dependency>
			<groupId>org.openid4java</groupId>
			<artifactId>openid4java</artifactId>
			<version>0.9.5</version>
		</dependency>
	</dependencies>	
</project>

简单复述一遍流程：

用户登陆网站(简称A),A提供选择：

1：用A的账户登陆。

2：用google的账户登陆。

用户想“俺有个google openid账户，我不想重新注册A账户”。他就选择用google openid账户登陆。

A站点就要知道google的openid provider endpoint的url,向这个地址请求,这一步叫discovery.

endpoint会返回一个文档(可能是xrds格式或html格式),例如google返回的xrds格式:

<?xml version="1.0" encoding="UTF-8"?>
<xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)">
  <XRD>
  <Service priority="0">
  <Type>http://specs.openid.net/auth/2.0/server</Type>
  <Type>http://openid.net/srv/ax/1.0</Type>
  <Type>http://specs.openid.net/extensions/ui/1.0/mode/popup</Type>
  <Type>http://specs.openid.net/extensions/ui/1.0/icon</Type>
  <Type>http://specs.openid.net/extensions/pape/1.0</Type>
  <URI>

可以看到uri里面就是下一步进行认证的地址。

A就要向这个uri请求认证，这个里面要设置一些参数用来进行交互比如说交换用户信息(AX),或是简单注册(Sreg)。当然要传入用户输入的openid账号。以及验证成功后接受google信息的url(openid.return_to)。google验证完成后会请求openid.return_to设置的网址，如果成功，会将需要的用户信息使用参数传入。

在这最后一步需要验证返回是否是安全的（中途是否被修改）:

1：检查openid.return_to和请求的地址是否匹配；

2：检查discovery信息。

3：检查openid.response_nonce

4：检查签名

------------------------------------------

我再使用规范2.0的复述一遍:

1 The end user initiates authentication by presenting a User-Supplied Identifier to the Relying Party via their User-Agent. 

用户向RP提交openid.

2 After normalizing the User-Supplied Identifier, the Relying Party performs discovery on it and establishes the OP Endpoint URL that the end user uses for authentication. It should be noted that the User-Supplied Identifier may be an OP Identifier, as discussed in Section 7.3.1, which allows selection of a Claimed Identifier at the OP or for the protocol to proceed without a Claimed Identifier if something else useful is being done via an extension.

RP使用openid执行discovery操作。openid中包含了将要请求的OP地址相关信息。OP对discovery返回的信息中包含了OP Endpoint 信息，下一步将要使用这些信息。openid还可能仅仅是OP的标识符而不是用户的openid标识符。

3 (optional) The Relying Party and the OP establish an association -- a shared secret established using Diffie-Hellman Key Exchange [RFC2631]. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; this removes the need for subsequent direct requests to verify the signature after each authentication request/response.

关联，密钥交换，这一步不是必需的，但是如果使用了这一步，那么最后的验证(7)就不是必需的。

4 The Relying Party redirects the end user's User-Agent to the OP with an OpenID Authentication request.

RP跳转用户到OP的登陆页面。

5 The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so. The manner in which the end user authenticates to their OP and any policies surrounding such authentication is out of scope for this document.

OP完成对用户的验证

6 The OP redirects the end user's User-Agent back to the Relying Party with either an assertion that authentication is approved or a message that authentication failed.

OP跳转用户到RP提供的returnto页面，并提供验证信和其他扩展属性。

7 The Relying Party verifies the information received from the OP including checking the Return URL, verifying the discovered information, checking the nonce, and verifying the signature by using either the shared key established during the association or by sending a direct request to the OP.

RP验证返回的信息是否可靠。(如果使用了association这一步，那么就不需要。因为直接可以通过交换的密钥来验证返回。)

-----------------

要认识到openid和cas的sso是两种风格，openid对于不同公司不同网站，典型的登陆操作是，即使用户已经登陆了provider的网站，但是即使他再打开consumer的网站，consumer网站任然是不知道此用户已经登陆的。用户想要登录consumer网站，还需要进入登陆页面，这个时候给予用户使用provider网站账户登陆的选项。用户选择使用provider网站账户登陆后，由consumer的网站自动与provider网站交互完成登录过程。典型的例子可看 http://translate.uservoice.com/ 中的google登录方式。

但是如果是同一个公司，不同的网站，要通过openid实现类似CAS的方式，也是可行的，每个网站都使用过滤器来检查用户是否已经在主站(provider)登陆，将用户信息拿过来就行了。即discovery这一步是固定的。

==========================================

参考:

http://r-j-r-a5438-163-com.iteye.com/blog/611351

http://www.360doc.com/content/08/0507/11/7349_1242557.shtml

http://code.google.com/p/openid4java/w/list

http://code.google.com/p/openid-server/