跳转到内容

OpenID：修订间差异

维基百科，自由的百科全书
以互动方式浏览历史
←上一版本下一版本→
删除的内容 添加的内容
可视化wikitext
BornNF（留言 | 贡献）
6次编辑
无编辑摘要
BornNF（留言 | 贡献）
6次编辑
第32行： 第32行：
假设用户Alice在身份提供者openid-provider.org处注册了一个OpenID标识：alice.openid-provider.org。如果Alice想使用这个标识来登录example.com，她只需要到example.com去将alice.openid-provider.org填入OpenID登录表单。
假设用户Alice在身份提供者openid-provider.org处注册了一个OpenID标识：alice.openid-provider.org。如果Alice想使用这个标识来登录example.com，她只需要到example.com去将alice.openid-provider.org填入OpenID登录表单。


如果标识是一个URL，依赖方example.com做的第一件事情是将这个URL转换为典型格式，如：http://alice.openid-provider.org/。在OpenID 1.0中，依赖方接着请求该URL对应的网页，然后通过一个HTML链接tag发现提供者服务器，比如http://openid-provider.org/openid-auth.php。同时也确定是否应该使用授权身份（delegated identity）。从OpenID 2.0开始，依赖方请求的是XRDS文档（也称为Yadis文档），使用内容类型application/xrds+xml。这种类型在URL中可能存在，而在XRI中总是存在。
如果标识是一个URL，依赖方example.com做的第一件事情是将这个URL转换为典型格式，如：http://alice.openid-provider.org/。在OpenID 1.0中，依赖方接着请求该URL对应的网页，然后通过一个HTML链接tag发现提供者服务器，比如http://openid-provider.org/openid-auth.php 。同时也确定是否应该使用授权身份（delegated identity）。从OpenID 2.0开始，依赖方请求的是XRDS文档（也称为Yadis文档），使用内容类型application/xrds+xml。这种类型在URL中可能存在，而在XRI中总是存在。


依赖方可以通过两种模式来与身份提供者通信：
依赖方可以通过两种模式来与身份提供者通信：
第41行： 第41行：
首先，依赖方与身份提供者建立一个“共享秘密” —— 一个联系句柄，然后依赖方存储它。如果使用checkid_setup模式，依赖方将用户的网页浏览器重定向到提供者。在这个例子里，Alice的浏览器被重定向到openid-provider.org，这样Alice能够向提供者验证自己。
首先，依赖方与身份提供者建立一个“共享秘密” —— 一个联系句柄，然后依赖方存储它。如果使用checkid_setup模式，依赖方将用户的网页浏览器重定向到提供者。在这个例子里，Alice的浏览器被重定向到openid-provider.org，这样Alice能够向提供者验证自己。


验证的方法可能不同，但典型地，OpenI提供者要求提供密码（然后可能使用cookies存储用户会话，就像很多基于密码验证的网站的做法一样）。如果Alice当前没有登录到openid-provider.org，她可能被提示输入密码，然后被问到是否信任依赖方页面 —— 如http://example.com/openid-return.php，这个页面被example.com指定为用户验证完成后返回的页面 —— 获取她的身份信息。如果她给出肯定回答，OpenID验证被认为是成功的，浏览器被重定向到被信任的返回页面。如果Alice给出否定回到，浏览器仍然会被重定向，然而，依赖方被告知它的请求被拒绝，所以example.com也依次拒绝Alice的登录。
验证的方法可能不同，但典型地，OpenI提供者要求提供密码（然后可能使用cookies存储用户会话，就像很多基于密码验证的网站的做法一样）。如果Alice当前没有登录到openid-provider.org，她可能被提示输入密码，然后被问到是否信任依赖方页面 —— 如http://example.com/openid-return.php ，这个页面被example.com指定为用户验证完成后返回的页面 —— 获取她的身份信息。如果她给出肯定回答，OpenID验证被认为是成功的，浏览器被重定向到被信任的返回页面。如果Alice给出否定回到，浏览器仍然会被重定向，然而，依赖方被告知它的请求被拒绝，所以example.com也依次拒绝Alice的登录。


但是，登录的过程还没有结束，因为在这个阶段，example.com不能够确定收到的信息是否来自于openid-provider.org。如果他们之前建立了“共享秘密”，依赖方就可以用它来验证收到的信息。这样一个依赖方被称为是stateful的，因为它存储了会话间的“共享秘密”。作为对比，stateless的验证方必须再作一次背景请求（check_authentication）来确保数据的确来自openid-provider.org。
但是，登录的过程还没有结束，因为在这个阶段，example.com不能够确定收到的信息是否来自于openid-provider.org。如果他们之前建立了“共享秘密”，依赖方就可以用它来验证收到的信息。这样一个依赖方被称为是stateful的，因为它存储了会话间的“共享秘密”。作为对比，stateless的验证方必须再作一次背景请求（check_authentication）来确保数据的确来自openid-provider.org。

2007年12月16日 (日) 08:42的版本

OpenID 是一个去中心化的单一登陆身份系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者(identity provider, IdP)的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登陆的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了问题而又不需要依赖于中心性的网站来确认数字身份。

OpenID正在被越来越多的大网站采用，比如作为身份提供者的AOL和Orange。另外，Firefox 3将集成OpenID支持作为高优先级处理；OpenID可以和.NET Framework的Windows CardSpace一起使用。

历史

OpenID最初由LiveJournal的Brad Fitzpatrick开发，后来加入了Light-Weight Identity，Yadis，Sxip DIX protocol和XRI/i-names。未来的OpenID规范正在由OpenID.net开发，很多技术公司、服务公司和开源开发者都参与其中。

为了推动OpenID的应用，2006年8月，一些公司赞助设立了OpenID奖励计划，对前10位满足要求的软件项目各奖励5000美元。

2007年12月5日，OpenID验证规范2.0和属性交换规范1.0发布。

使用OpenID

OpenID相关基本术语：

最终用户(End User)

想要向某个网站表明身份的人。

标识(Identifier)

最终用户用以标识其身份的URL或XRI。

身份提供者(Identity Provider, IdP)

提供OpenID URL或XRI注册和验证服务的服务提供者。

依赖方(Relying Party, RP)

想要对最终用户的标识进行验证的网站。

登录

一个想要为其访问者提供OpenID登录网站，比如example.com，需要在页面的某个地方放置一个登录表单。与提示用户输入用户名和密码的传统登录表单不同的是，这种表单只有一个输入框:OpenID标识。网站可以选择在这个输入框旁显示一个小的OpenID图标。这个表单与OpenID客户端库的实现相连接。

假设用户Alice在身份提供者openid-provider.org处注册了一个OpenID标识：alice.openid-provider.org。如果Alice想使用这个标识来登录example.com，她只需要到example.com去将alice.openid-provider.org填入OpenID登录表单。

如果标识是一个URL，依赖方example.com做的第一件事情是将这个URL转换为典型格式，如：http://alice.openid-provider.org/。在OpenID 1.0中，依赖方接着请求该URL对应的网页，然后通过一个HTML链接tag发现提供者服务器，比如http://openid-provider.org/openid-auth.php 。同时也确定是否应该使用授权身份（delegated identity）。从OpenID 2.0开始，依赖方请求的是XRDS文档（也称为Yadis文档），使用内容类型application/xrds+xml。这种类型在URL中可能存在，而在XRI中总是存在。

依赖方可以通过两种模式来与身份提供者通信：

  • checkid_immediat: 两个服务器间的所有通信都在后台进行，不提示用户。
  • checkid_setup: 用户使用访问依赖方站点的同一个浏览器窗口与身份提供者服务器交互。

第二种模式更加常用。而且，如果操作不能够自动进行的话，checkid_immediate模式会转换为checkid_setup模式。

首先，依赖方与身份提供者建立一个“共享秘密” —— 一个联系句柄，然后依赖方存储它。如果使用checkid_setup模式，依赖方将用户的网页浏览器重定向到提供者。在这个例子里，Alice的浏览器被重定向到openid-provider.org，这样Alice能够向提供者验证自己。

验证的方法可能不同，但典型地，OpenI提供者要求提供密码（然后可能使用cookies存储用户会话，就像很多基于密码验证的网站的做法一样）。如果Alice当前没有登录到openid-provider.org，她可能被提示输入密码，然后被问到是否信任依赖方页面 —— 如http://example.com/openid-return.php ，这个页面被example.com指定为用户验证完成后返回的页面 —— 获取她的身份信息。如果她给出肯定回答，OpenID验证被认为是成功的，浏览器被重定向到被信任的返回页面。如果Alice给出否定回到，浏览器仍然会被重定向，然而，依赖方被告知它的请求被拒绝，所以example.com也依次拒绝Alice的登录。

但是，登录的过程还没有结束，因为在这个阶段，example.com不能够确定收到的信息是否来自于openid-provider.org。如果他们之前建立了“共享秘密”，依赖方就可以用它来验证收到的信息。这样一个依赖方被称为是stateful的，因为它存储了会话间的“共享秘密”。作为对比，stateless的验证方必须再作一次背景请求（check_authentication）来确保数据的确来自openid-provider.org。

Alice的标识被验证之后，她被看作以alice.openid-provider.org登录到example.com。接着，这个站点可以保存这次会话，或者，如果这是她的第一次登录，提示她输入一些专门针对example.com的信息，以完成注册。

OpenID不提供它自己的验证方式，但是如果身份提供者使用强验证，OpenID可被用于安全事务，比如银行和电子商务。

推广

AOL 與 Yahoo! 都已經支援 OpenID。AOL 提供每個 AOL 或 AIM 的使用者一組 OpenID Identity，目前還在測試階段，為 openid.aol.com/username。Yahoo! 則是由第三方透過 Yahoo! API 轉換成 OpenID，目前由 idproxy.net 提供。

目前使用 OpenID 代替一般帳號密碼的網站包括了 LiveJournal、Zooomr、Wikitravel、ma.gnolia.com、claimid.com 以及 Jyte。

在 openid.net 上有一份公開的伺服器列表，可以讓一般人申請 OpenID Identity。

運作方式

法律問題

参考文献

OpenId英文维基百科条目

¹== 外部链接 ==

检索自“https://zh.wikipedia.org/w/index.php?title=OpenID&oldid=5809776”