OpenID-共享文化- 科技百科 -互联网博物馆，你我的知识加油站

　　OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散、自由等特性。

　　OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫 URL 或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。由于URI 是整个网络世界的核心，它为基于URI的用户身份认证提供了广泛的、坚实的基础。

OpenID基金会会议

　　OpenID 系统的第一部分是身份验证，即如何通过 URI 来认证用户身份。目前的网站都是依靠用户名和密码来登录认证，这就意味着大家在每个网站都需要注册用户名和密码，即便你使用的是同样的密码。如果使用 OpenID （参见规范），你的网站地址（URI）就是你的用户名，而你的密码安全的存储在一个 OpenID 服务网站上（你可以自己建立一个 OpenID 服务网站，也可以选择一个可信任的 OpenID 服务网站来完成注册）。

同一个网络同一个ID编辑本段 回目录

　用户们希望拥有一个可以访问所有网站的通用ID，但其中蕴藏的风险让许多网站踌躇不前。OpenID也许是目前最有可能实现这一梦想的希望之星了。

　　文 Richard Martin 译李林

OpenID标识

　　今年7月，当社交网络巨头MySpace宣布采用OpenID的消息传出后，这个通用登录体系的支持者立即为之欢呼雀跃。

　　OpenID基金会（OpenID Foundation）的执行董事比尔·沃什本（Bill Washburn）表示，随着MySpace的加入，OpenID支持的用户数量现已超过5亿。“显然，OpenID的发展势头才刚刚启动而已。”他说。

　　OpenID是“以用户为中心的ID变革运动”带来的最直观的高度演变成果之一。这一运动倡导的是建立一个由用户控制的通用型在线个人身份管理机制，将个人身份预存在一个安全的地方（如用户本地电脑或互联网云中），在需要网络注册时只需点击鼠标调用即可。一旦这种模式得到广泛的采纳，OpenID就能让网络用户畅游各种网站，免受重复注册登录之累。

　　OpenID是布拉德·菲茨帕特里克（Brad Fitzpatrick）于2005年创始的，而它的开发工作则是由一群随性所至的编程师来完成。独立非营利性组织OpenID基金会是这一通用登录体系背后的主要推出力量。今年2月，国际商业机器公司（IBM）、谷歌公司（Google，下称谷歌）、微软公司（Microsoft，下称微软）、威瑞信公司（VeriSign，下称威瑞信）及雅虎公司（Yahoo，下称雅虎）都加入了该基金会的董事会。

　　现阶段OpenID面临的问题是，MySpace以及其他支持这一体系的技术巨头只提供OpenID功能，但并不真正接受它。换句话说，在协议之下你可以用MySpace的帐号在其他网站上登录，但MySpace却不支持其他提供商的OpenID帐号在自己网站上登录。

　　“这就像条单行道，”伯顿集团（Burton Group）的副总裁兼身份管理研究总监鲍勃·布雷克里（Bob Blakley）说，“这意味着他们愿意看到创建OpenID为别人带来的风险，但如果这份风险降临到自己头上就不愿意接受了。”

　　一处注册，处处通用

　　OpenID的运作原理是将某一现有URL（如http://rmartin.myopenid.com）与一组标示符相关联，以便其他网站能够进行分辨和识别，进而获得其信任。你只需将URL输入OpenID的登录框中，就再不必填写国家省份、电话号码以及父母姓名等繁琐的注册和验证信息了。

　　以灾荒救济组织国际乐施会（Oxfam International）的网站为例。这是接受OpenID的1.5万余家网站之一，在其首页上有一个“用OpenID登录”的方框，你只要输入自己的OpenID URL，网站服务器就会自动访问这一URL，并从链接标签中获取OpenID提供商的地址。

　　利用Diffie-Hellman密钥安全交换协议，两家网站的服务器会建立一个共享的秘密协议，在不通过互联网交换的情况就能验证你的OpenID。你会被重新转到OpenID提供商的网站上（如MyOpenID.com），然后在那里进行身份验证——一般只需填写密码即可。OpenID提供商会把登录所需的所有个人信息都转交给乐施会网站。

　　潜在风险

　　对于电子商务网站而言，ID的分配和转移是个尤为棘手的问题。它们想让用户能轻松登录网站，但又不愿承担单点式通用登录所带来的风险。目前的情况是，接受OpenID就像是养了一条大丹狗一样，一方面你很乐意自己家里有这么一条狗看家护院，但另一方面却很反感它招来一大群同类吵得家里不得安宁。

　　OpenID的风险可分为两大类：由用户承担的风险，以及由接受OpenID登录的网站（即所谓的“依赖方”）所承担的风险。对于用户而言，其中的风险显而易见：由于大部分用户要转到OpenID提供商的网站进行密码验证，因此系统很容易受到钓鱼软件的攻击。

　　微软的身份与访问首席架构师吉姆·卡梅隆（Kim Cameron）在自己的博客IdentityBlog上这样写道：“OpenID提供了很大的便利，但与其他所有单点式登录技术一样，面临着相同的潜在风险。这种模式越受欢迎，钓鱼软件的可乘之机也就越大。”

　　对于提供商而言，没有任何人能担保用户的身份信息是真实无误的。“OpenID提供商在为用户开设帐户之前，通常不会对其背景进行调查，也不会要求其提供能证明个人身份的细节信息。”伯顿集团的布雷克里表示，“鉴于这种原因，大多数OpenID的身份可信度都非常低。”

　　这种与生俱来的特点，意味着OpenID很难被用于银行转账等高价值的交易当中。“OpenID如果不提高安全系数，那在市场上就无法与信息卡等更加可靠的解决方案争长较短。”信息卡提供商、OpenID基金会董事局成员奇偶通讯公司（Parity Communications）的基础设施副总裁德拉姆蒙德·里德（Drummond Reed）表示。

　　开放的标准

OpenID示意图

　　从设计上来说，OpenID本就不是一个高度安全可靠的体系。它只是方便网站在识别用户时，将同一URL源的信息进行共享的一种开放标准而已。它天生就不具备安全和认证的功能特点，正如OpenID基金会董事长斯科特·克维登（Scott Kveton）所说：“OpenID的验证方式实际上与安全协议完全无关。在这种情况下，究竟为OpenID采用何种程度的安全保护措施，全由你自己决定。”

　　大多数用户在选择安全验证时，总是挑最简单的。这样一来，他们的OpenID登录点就会是注册时随手选择的一家网站。也就是说，如果你是在陶瓷工房（Pottery Barn）或是亚马逊（Amazon）的网站上创建OpenID帐户，那么该网站就会成为你的提供商。你的个人信息会储存在提供商那里，并且你今后在网上的任何活动都会与之捆绑在一起。正因为此，提高OpenID的安全系数才会显得如此重要。

　　一些安全厂商推出了相关的认证工具，如威瑞信的VIP，JanRain公司的CallVerifID以及Vidoop的ImageShield等，它们都能与OpenID配套使用，并提供密码之外的用户认证方式。比如，威瑞信使用的就是“双因素认证”，包括你知道的内容因素（如密码等），以及你拥有的物品因素（如信息卡、安全令牌、手机等）。

　　微软在1999年投放市场的Passport可迁移性ID产品无果而终，如今该公司又推出了名为CardSpace的“视觉信息卡”技术，用于支持OpenID。CardSpace让用户使用一套已储存的身份来进行登录，这套身份在用户界面中以“数码卡”的形式来表示。用户可以选择想用的信息卡身份，然后将其递交给想要访问的网站。之后，CardSpace软件会提供一个包含必要登录信息的XML令牌。

　　当在OpenID 提供商的网站上进行验证时，CardSpace可代替密码的作用，它会向网站发送一个用暗号写成的“验证语”，这样就能防止钓鱼或木马软件的攻击。要想让单点式通用登录成为现实，“我们认为就得让OpenID与CardSpace联姻，如此一来用户的安全隐私才能获得保障。”微软的身份与访问总监J.G.齐拉普拉斯（J.G. Chirapurath）表示。

　　信任问题

　　和很多事情一样，说到底，最终的问题还是“你究竟信任谁？”由于OpenID是一个开放的标准，因此便没有一个监管机构来约束每个人都按规则办事。这里唯一的规则就是：OpenID有风险，使用需谨慎。

　　“现在的问题是，针对市场上的众多应用程序，在基础的身份技术之上应当有一层管理机制。”微软的卡梅隆说，“如果某个环节出了岔子怎么办？那些提供商的可靠性和服务质量有无保证？如果信息泄露了，那该追究谁的责任？”正是这一系列问题，阻碍了OpenID在电子商务世界中的推行。

　　建立这样的管理和问责机制需要花费时间，但这种事情不是投入了精力和时间就一定能够成功的。目前，为了实现通用登录这个完美的理想，起码有半打机制正在研发当中。其中一些是针对合作网站之间安全交换信息认证和授权而开发的框架或协议，如安全性断言标记语言（Security Assertion Markup Language，下称SAML），而另一些则是横跨网站、应用程序和设备而搭建的，将身份、简介以及关系信息融为一体的构架，如希金斯计划（Higgins Project）。微软当下正在大力推进自己的CardSpace。而与OpenID基金会类似，致力于行业标准的组织自由联盟（Liberty Alliance）也在试图创建一个解决网络ID问题的整体化途径。

　　自由身份咨询师卡利亚·汉姆林（Kaliya Hamlin）是互联网身份讨论会（Internet Identity Workshops）的组织者，同时他还负责维护一个主要的在线身份社区中心。他认为，总有一天所有的这些框架都会被组合到一块儿。不过，就目前而言，它们之间还缺乏关联的组件和设计，在外行人看来这就像是一幅杂乱无章的拼图一样。

　　希望之星

　　尽管还存在一些缺陷，但OpenID仍是最有希望获得业界广泛接受的协议。然而，眼下OpenID还不具备足够的魅力来吸引大型企业敞开怀抱接纳自己。

　　OpenID基金会董事长克维登表示，采用OpenID的网站数量正以每周5％的速度递增。这当然是一个很惊人的数字，但只有当亚马逊、美国在线（AOL）、微软、雅虎以及其他网络霸主们接纳了OpenID，以用户为中心的ID运动才会真正迎来春天。到目前为止，还没有哪家金融机构宣布使用OpenID。正如惠普公司（Hewlett-Packard）的身份管理服务主管皮特·默特鲁拉斯（Pete Metrulas）所说，这项运动目前缺乏的，是“一场有关OpenID能为大型企业带来何种价值的讨论”。

　　这么说起来，OpenID仿佛很难有大的作为，但现在就下定论还为时尚早。不管怎么说，以用户为中心的ID运动是有各大互联网厂商做后盾的，光这一点就足以为其提供动力保证。随着OpenID的个人用户数量不断增加，采用它的网站也会越来越多。

　　当然，在OpenID或其他通用ID协议背后，最有价值的动力实际上就是用户自身的个人信息。在这个以消费者为导向的Web 2.0时代，个人信息的价值毋庸多言。为了搜罗这些信息，各大网站都用过高级访问权、优质服务和会员折扣这些手段来诱使用户注册。通用登录在这方面展现出的好处，精明的网站是不会视而不见的。

　　用默特鲁拉斯的话来讲，在OpenID帮助下，网站可以存储、共享和管理“更深层次的用户数据”，并将它们转化为商业价值。这样的一个未来让许多公司眼馋不已。通过集中储存信息财富，并给予用户进入“库房”添加财富的钥匙，我们不难想象这将会是多么庞大的一个潜在市场。

　　只有兴旺发展的市场，才能带动OpenID的推广和用户中心ID运动的壮大。电子前沿基金会（Electronic Frontier Foundation）的董事长布拉德·滕布里顿（Brad Templeton）认为，目前那些框架计划的问题在于，它们都没有考虑到市场的力量，因为“用户个人是没有资本和网站讨价还价的。”

　　OpenID现在只是一把开不了多少锁的钥匙。用户们需要的是一个能将他们的个人信息物尽其用的交换体系。“只有用户和网站双方进行协商才能解决问题。”滕布里顿说。消费者可指派一个自己信得过的机构作为代理人，它们可以是OpenID提供商，如你的母校或MyOpenID。“无论如何，用户必须找到一些在谈判桌上可以利用到的筹码。”如若不然，你就只有乖乖地按照网站的规则去注册，交出自己宝贵的个人信息。这样的一个互联网世界，恐怕不是我们所能长期忍受的。

OpenID协议综述编辑本段 回目录

　OpenID协议非常易于扩展，下面的图表展示了OpenID2.0草案的基本工作流程。它展示了在终端用户、Relying Party站点（一个示例站点）和OpenID服务提供者之间的交互过程（最常见的认证流程）。

　　用户登入外部站点的过程主要分为以下七个步骤：

1. Relying Party站点请求用户标识

　　此步骤非常简单：用户提供一个字符串（以URL或者XRI格式）给外部站点，使后者能够识别用户。

　　1.外部站点请求用户发送标识。通常使用带有Open图标的文本输入框、用于提交信息的按钮组成的form来完成此功能。为了方便起见，文本输入框的name属性应为openid_identifier，这样以便浏览器自动将其识别为一个OpenID登录form。

　　2.用户输入标识，标识可能采用下面的形式：

　　? URI/URL (通过http或者https)

　　? XRI。XRI是一种广义的、分散式的URI。它能用于任何使用URI的地方。XRI主要采用以下形式：xri://authority/path?query#fragment。了解更多关于XRI的信息请看：XRI语法规范。

　　用户标识类似这个样子：http://myname.myhost.com/。外部站点经常将OpenID logo放置到其登录form上，这样可以使你很快地辨别出是否使用OpenID。

　　用户在点击位于外部站点登录页面上的“Login”按钮后便启动了认证过程。

2.“标准化”

　　2.“标准化”: Relying Party站点整理用户标识

　　用户输入了标识后，此标识便由外部站点进行整理（标准化）。由于标识可能使用XRI或者URI格式，因此整理的过程非常复杂：

　　1.如果标识以xri://、xri://$ip或者xri://$dns*开头，那么我们要去掉这些头部标记。

　　2.如果余下字符串中的第一个字符是XRI的全局上下文符号（=、@、+、 $、!），那么此字符串为标准的XRI标识。否则，将被视为HTTP URL（如果http/https前缀没有定义，我们需要为其添加上http://）。当然，URL必须遵守URL命名规范。最终获得的URL就是一个标准的URL标识。

　　下面是一些示例：

　　下面的流程图描绘了标准化处理过程：

3.“发现”

　　3.“发现”: Relying Party站点查询与OpenID服务器进行通讯的方式

　　外部站点使用标准化的标识来查询用于发起请求所必须的信息。对于“发现”阶段来讲，其使用的解析协议和获取的结果文档都取决于在标准化阶段决定的标识类型。这正是OpenID2.0规范的特殊之处。

　　快速参考:

　　? XRI 解析:类似通过UDP将主机名解析为IP的DNS协议；它将XRI转换为XRDS。其目的是提供一种将厚重、通用的XRI格式转换为真实可用的描述符。

　　? YADIS协议:将URL连接到XRDS上。这是一种非常简单的协议，它将当前的HTTP或者HTTPS URL直接指向XRDS。

　　? XRDS：一种基于XML的XRI资源描述符。它被设计用来提供关于XRI的可用的、描述性信息。在OpenID应用场合中，XRDS用来描述OpenID服务器，并且使用“priority”参数标识了用户对服务器的优选顺序。在下面的示例中，http://www.livejournal.com/users/frank具有最高的优先权（最低的数值）：

　　<?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>部分必须提供以下标签：

　　可选的，如果用户使用委派（delegation）（就是用户宣称拥有一个不存在于该OpenID服务器上的本地标识），则需要使用下面的标签：

　　例如，某人正在使用openidprovider.com这个OpenID服务器来验证他在另一个OpenID服务器usersite.com上的身份，那么其本地标识将使用类似user.openidprovider.com的形式。

　　这个“发现”的过程允许外部站点知道两件事，其中一件是外部站点如何与OpenID服务器进行通讯：

　　1.OpenID提供者端点URL：OpenID提供者的最终URL（服务器URL）。

　　2.认证协议版本: OpenID认证使用的协议版本。

　　作为可选的，如果用户使用委派，那么外部站点将需要知道：

　　1.用户宣称的标识：此标识为用户宣称属于自己的。它是在登录过程中用户提供过的标识。

　　2.本地标识（OP-Local Identifier）:用户在其OpenID服务器上拥有的本地标识。

　　例如，用户使用http://www.example.com/作为其标识，但外部网站实际上通过https://www.exampleprovider.com/endpoint/这个OpenID服务器来验证用户标识https://exampleuser.exampleprovider.com/。那么在对http://www.example.com/执行发现的过程中，我们需要在XRDS文档的最后一个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

　　4. Relying Party站点建立与OpenID服务器之间的关联(可选)

　　通过在外部站点和OpenID服务器之间的关联（association），我们可以建立一种在两者之间共享的加密通道，它可以用来验证后续的协议信息并降低通讯回合数。在OpenID规范中对于实际创建关联的过程进行了详尽的描述。简单来讲就是使用了一种Diffie-Hellman密钥交换算法来生成共享密钥。此密钥用于对信息进行签名。

　　这样使得外部站点和OpenID服务器之间能够安全地通讯。这里指的“安全性”是通过传输层（使用SSL）或者通过应用层的HMAC SHA1或者HMAC SHA256算法实现的。关联请求的成果就是assoc_handle（关联权柄），外部站点和OpenID服务器将在本次关联的后继活动中将它作为对消息进行加密的密钥。

　　关联阶段被标为“可选的”，这是因为OpenID协议还允许外部站点直接请求认证（不作关联）、并且接着请求对认证信息进行验证。这样外部站点可以不保有关联权柄信息，以实现无状态通讯。而这种方式被推荐用于执行与OpenID服务器之间的相关通讯，但如果不能使用此方式的话，就必须创建上面讲的关联方式。

5. Relying Party

　　5. Relying Party站点请求认证

　　我们通过使用重定向页面可以建立认证请求。请查看下表中的重要参数值，详细信息请参考OpenID相关信息格式文档：

　　请注意：外部站点并没有直接发送HTTP请求到OpenID服务器，而是重定向到OpenID服务器页面。由于这样使得OpenID服务器能够从用户浏览器中读取cookie而没有将任何认证细节泄露给外部站点，因此这个过程是安全的。

6. OpenID

　　6. OpenID服务器回应认证请求

　　在接收到OpenID认证请求后，OpenID服务器必须决定允许还是拒绝此用户的认证。这将由用户从前是否在OpenID服务器上认证过决定。

　　请注意：OpenID服务器在接收认证请求信息时是具有控制权的。这意味着它不但能够异步地回应认证请求信息，并在它回应认证请求之前与用户进行一系列的交互。大多数认证服务器都提供给用户一个页面使其能够选择允许或者拒绝来自外部站点的认证请求。

　　一旦OpenID服务器已经回应了认证请求，那么它将创建一个如下描述的认证回应信息，低层信息细节请阅读OpenID协议文档：

　　此回应通过将用户重定向到外部站点的方式发送，以确保外部站点和OpenID服务器之间在认证请求/回应过程中没有直接通讯。

7. 验证间接回应
　　协议的最后一步是外部站点验证这个发自OpenID服务器的间接认证回应信息。

　　当外部站点接收到回应时，它必须在接受其内容之前进行下面的验证：

　　? “openid.return_to”的参数值是否匹配当前请求的URL。这确保OpenID服务器重定向用户、发送回应信息到正确的URL。

　　? 被发现的信息是否与回应信息相匹配。

　　? 具有相同参数值的“openid.response_nonce”表示OpenID服务器遭到了重放攻击(reply attacks)。

　　? 在回应信息中的签名是否有效、要求的签名域是否都被签名。这保证认证信息没有被篡改过。　OpenID协议提供了一个基本的认证机制。目前还有基于OpenID的其它可用协议：

　　? Attribute Exchange：OpenID属性交换是一种用于在端点之间交换标识信息OpenID服务扩展。其提供了对标识信息的接收和存储。

　　? Simple Registration：这是OpenID认证协议的扩展，它允许非常轻量级的配置交换。主要用于在终端用户使用web服务注册新帐号时传送八种常用的请求信息。

　　使用OpenID4Java实现OpenID协议

　　OpenID4Java是对OpenID1.1和2.0规范的实现，目前它通过code.google.com系统进行维护。此项目初始代码是由Sxip捐献出来的，而后Atlassian等公司参与进来，并为实现支持2.0规范（属性交换规范）的API贡献了大量的工作。

　　在使用OpenID4Java之前，你需要完成以下工作：

　　? 下载OpenID4Java代码库，并将其安装到你的项目中。

　　? 修改你的认证提示，使其询问用户的OpenID标识，而不是从前的用户名和密码。

　　? 创建针对用户标识的认证请求，并将用户重定向到他们的OpenID服务器。

　　? 在返回URL中接收OpenID提供者的认证回应并进行验证。

　　这样，你的web应用就会像在上面协议综述中的流程图所展示的“Relying Party”那样工作。

　　第一步是创建消费者对象，它将向认证服务器发出认证请求。这里我们将消费者对象视为一个贯穿应用的个体，以使相关的关联密钥能够保存在同一位置。因为当面临多个认证请求时，在不同的请求之间保存密钥将在两个端点（请求和回应端点）间引起下幅度的性能下降。

　　Sample Consumer代码片段：

　　/** * Sample Consumer (Relying Party) implementation. */public class SampleConsumer{ public ConsumerManager manager; public SampleConsumer() throws ConsumerException { // instantiate a ConsumerManager object manager = new ConsumerManager(); } ...}

　　一旦用户提供了OpenID URL，你就需要获取OpenID认证服务器的端点URL，发送请求到此URL。而OpenID认证服务器的端点被确定后，你还要创建一个和服务器关联的共享密钥。

　　// discover the OpenID authentication server's endpoint URLList discoveries = manager.discover(userSuppliedOpenID);// attempt to associate with the OpenID provider// and retrieve one service endpoint for authenticationDiscoveryInformation discovered = manager.associate(discoveries);// store the discovery information in the user's session for later usesession.setAttribute("discovered", discovered);

　　以上的调用将完成：

　　? 下载OpenID提供者列表（一般只有一个提供者）。返回结果将按照用户指定的优选顺序排列。

　　? 通过关联获取和OpenID提供者之间的共享密钥。

　　? 将关联（发现信息）保存，以备之后的使用。

　　我们现在需要将用户重定向到他们的OpenID提供者页面，并告诉OpenID提供者外部站点的地址（返回URL，这里就是你的站点），以使OpenID提供者知道在执行完认证后将用户发送到哪里。

　　// define the return pathString returnURL = "http://company.com/openidresponse.jsp";// generate an AuthRequest message to be sent to the OpenID providerAuthRequest authReq = manager.authenticate(discovered, returnURL);// redirect the user to their provider for authenticationhttpResp.sendRedirect(authReq.getDestinationUrl(true));

　　上面的代码将用户重定向到他们的OpenID提供者，在那里用户将被询问是否同意和你的站点进行认证。（请注意：无论用户同意“临时”授权给你的web应用、还是“总是”或者“不”授权，OpenID提供者都将保存此首选标识）。当用户再次访问你的web应用时，如果用户已经被OpenID提供者认证过并且在首次认证时选择了“总是”，那么此用户将可以访问你的web应用，而无需再次认证。

　　在认证用户之后，OpenID提供者将用户重定向到外部站点（由返回URL定义的web应用），并发送认证回应信息给你的web应用，而你的web应用将需要接收此回应。你可以显示错误信息或者将用户发送到“成功”页面，这完全取决于你的工作流。

参考文献编辑本段 回目录

http://finance.jrj.com.cn/2008/10/1313002266063.shtml

词条内容仅供参考，如果您需要解决具体问题
（尤其在法律、医学等领域），建议您咨询相关领域专业人士。本词条对我有帮助2

OpenID 发表评论(0) 编辑词条

同一个网络同一个ID编辑本段 回目录

OpenID协议综述编辑本段 回目录

参考文献编辑本段 回目录

对词条发表评论

OpenID 发表评论(0) 编辑词条

同一个网络 同一个ID编辑本段回目录

OpenID协议综述编辑本段回目录

参考文献编辑本段回目录

对词条发表评论

同一个网络同一个ID编辑本段回目录