Identity 2.0 的提法大约是 2005、2006 年间诞生的,是对一类
以用户为中心、支持跨域的身份认证机制的泛称。Identity 2.0 旨在替代现行网络系统上常用的用户名-密码验证机制,以解决用户名-密码机制的以下
缺点:
、
- 1,用户在不同网站上重复填写注册信息、记忆和管理密码的负担较重;
- 2,很多设计不周的网站使用 http 协议直接明文传输密码;
- 3,不能实现跨域的单点登录。
- 4,钓鱼网站的威胁;
- 5,键盘敲击用户名-密码有被恶意软件记录的危险;
OpenID 可能是目前 Identity 2.0 中影响力最大的一个。它最初由LiveJournal的Brad Fitzpatrick开发,后来加入了Light-Weight Identity,Yadis,Sxip DIX protocol和XRI/i-names。未来的OpenID规范正在由OpenID.net开发,很多技术公司、服务公司和开源开发者都参与其中。
OpenID 是一个
以用户为中心的数字身份认证框架,它具有
开放、分散、自由等特性。
OpenID 是一个去中心化的网上身份认证系统。对于支持OpenID的网站,用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是,他们只需要预先在一个作为OpenID身份提供者(identity provider, IdP)的网站上注册。OpenID是去中心化的,任何网站都可以使用OpenID来作为用户登录的一种方式,任何网站也都可以作为OpenID身份提供者。OpenID既解决了问题而又不需要依赖于中心性的网站来确认数字身份。
OpenID角色与术语:
- 终端用户(End User) — 使用OpenID作为网络通行证的互联网用户;
- 依赖方(Relying Party, RP) — OpenID支持方,支持End User用OpenID登录自己的网站;
- 身份提供者(Identity Provider, IdP, OpenID Provider, OP) — 提供OpenID URL或XRI注册和验证服务的服务提供者。
- 标识(Identifier) - 最终用户用以标识其身份的URL或XRI。
OpenID简单用户认证流程:
- 1,终端用户在OpenID Provider(OP)上面注册一个形同 URL 的 OpenID,此 OpenID 事实上仍要对应 OpenID provider 上的一组用户名-密码。
- 2,在支持 OpenID 的网站(RP)上,终端用户只需使用自己的 OpenID 登录。
- 3,该网站(RP)通过访问 OpenID URL 找到 OpenID provider,如果终端用户已成功登录OpenID provider(或在本地保存了有效的 Cookie),则 OpenID provider 向目标网站返回用户身份信息;
- 4,否则重定向到 OpenID provider 的登录界面,要求输入用户名-密码以验证用户对 OpenID 合法拥有。
OpenID详细用户认证流程(OpenID 1.0, OpenID 2.0):
- 一个想要为其访问者提供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能够向提供者验证自己。
- 验证的方法可能不同,但典型地,OpenID提供者要求提供密码(然后可能使用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对传统用户名-密码认证机制缺点的处理:
- 缺点1:在 OpenID 中不存在,但需要权衡的是在 OpenID 中保存多少个人信息,毕竟我们对不同目标网站的信任度是不同的;
- 缺点2:OpenID provider 通过使用 https 及数字证书来解决;
- 缺点3:解决了此缺点正是 OpenID 的最大亮点。
- 缺点4:用户只要记清楚 OpenID provider 的域名,不在 OpenID provider 以外输入用户名-密码,可以在一定程度上降低钓鱼网站的威胁(但钓鱼网站仍可以伪装成目标网站来欺骗用户,获取 OpenID provider 中的非敏感信息,只是得不到密码);
- 缺点5:OpenID 没有解决此缺点,但如果支持 OpenID 的网站多起来了,则可以大幅减少密码输入次数;
OpenID 带来的新问题是
单点失效(分布式,故障转移)
虽然网上有很多 OpenID provider,但一个 OpenID 只保存在一个 OpenID provider 中,只要这个服务器失效了,上面所有的用户就无法登录任何基于其验证身份的网站了。解决这个问题的方法之一是使用 OpenID 的
Delegation 机制,通过另一个相对安全稳定的 URL(称为“Delegating OpenID”,位于普通的 web 服务器上即可)指向 OpenID URL。一旦原来的 OpenID provider 失效,可以在另一个 OpenID provider 上注册新用户,并将原有的 Delegating OpenID 指向新 OpenID。这时凡使用 Delegating OpenID 注册的网站账户登录不受影响。但从本质上说,保存 Delegating OpenID 的 web 服务器仍有单点失效的危险,用户最好能自己控制 Delegating OpenID 的域名,以方便在 web 服务器失效时快速迁移。但这对于大众用户来说又是不现实的。
OpenID现状:
目前
OpenID Directory 收录的支持 OpenID 登录的网站有 800 多个,其中不乏 Blogger、SourceForge 等知名网站。
- 但相当多的网站没有把 OpenID 作为自己唯一的、主推的登录方式,很多网站只使用 OpenID 的登录认证功能,而自己独立管理用户个人信息。
- 不少网站只把 OpenID 作为一个别名,绑定到已有的用户名-密码之上。
- 还有部分网站的 OpenID 用户只能使用有限的功能(例如只能给 Blog 留言,不能建立自己的 Blog),不是一个完整的账号。
- 真正把 OpenID 作为唯一入口的网站并不多,CopyTaste 是一个例子;
- Twitterfeed 以前也是,不过现在支持(并且主推的是)用户名-密码登录方式。
OpenID现状的原因分析:
- 造成这种现状很可能是因为 OpenID 的可靠性问题(单点失效)没有得到有效的解决。
- 此外,开放的 OpenID provider 市场难免鱼目混珠,也使一些网站经营者对其望而却步,毕竟网站经营者要对自己的用户数据负责。
- 抛开这些,仅仅从技术角度说,OpenID 为了开发和使用的灵活,在使用模式上没有太多的规矩,但这反而可能使开发人员对其误用,造成包括数据不一致在内的诸多问题。
- 我就在 Twitterfeed 上遇到过这样的问题(与使用 Delegating OpenID 有关),好在它的开发者 Mario Menti 热心地帮我直接修改数据库得以解决。我还因为同时使用具有相同 Email 的普通账户和 OpenID 账户,在基于 Moodle 的 Impact English 中丢失了学习记录,最终也是请教师在后台查证的。
其他Identity 2.0实现:
Identity 2.0 何时真正到来?(二)处境尴尬的 Information Card
Identity 2.0 何时真正到来?(三)生财有道的 i-name
参考:
openid 官网中文版
Identity 2.0 何时真正到来?(一)小有所成的 OpenID
OpenID&Oauth
维基百科 - OpenID
分享到:
相关推荐
### OpenID 2.0:理解身份验证协议的精髓 #### 概述 OpenID Authentication 2.0,简称OpenID 2.0,是一种开放标准的协议,用于跨网站的身份验证,允许用户通过第三方身份提供商进行登录,而无需在每个网站上单独...
本篇文章将深入探讨如何利用ASP.NET Identity 2.0框架来扩展并集成自定义角色的访问控制。ASP.NET Identity是一个强大的用户认证和授权系统,它在.NET Framework 4.5及更高版本中被广泛使用,尤其适用于Web应用程序...
议程和幻灯片内容Introduction to the topic IAM - Identity and Access Management and related terminology.Short intro to Keycloak.Setup of the local environment the techlab is based on. OAuth 2.0 incl. ...
文件“IdentityModel-IdentityModel-cf6fa17”可能是该库的源代码或特定版本,IdentityModel是.NET生态中的一个库,专注于简化OAuth 2.0、OpenID Connect和其他安全协议的实现。这个文件名可能表示的是这个库的一个...
授权服务器兼容OAuth 2.0和OpenID Connect(OIDC)的授权服务器,仅用于演示目的,可用作OAuth2 / OIDC研讨会的一部分。目标此授权服务器应... 作为开源免费提供支持学习OAuth2 / OpenID Connect的努力(自学或作为...
这是一个粗略的基本库,我用来快速构建 OAuth 2.0 和 OpenID Connect (OIDC) 的 iOS 演示应用程序。 系统要求/依赖项 要求: 除了 Xcode 什么都没有 安装 无需安装。 只需将其添加到您的项目中并进行身份验证即可...
关于IdentityModel IdentityModel是.NET标准帮助程序库,用于基于声明的身份,OAuth 2.0和OpenID Connect。 由( 和( 创立并维护。 它是一部分,并根据其。 它已获得 (OSI批准的许可证)的许可。 有关项目文档,请...
`openid4java`是一个用Java语言编写的开发库,它实现了OpenID 1.1和2.0规范,为Java Web应用程序提供了集成OpenID认证的能力。 首先,我们需要理解`openid4java`库的核心组件和功能: 1. **身份提供者(Identity ...
3. **OpenID Connect**:虽然原始的OpenID规范主要是用于验证,但OpenID Connect在其基础上添加了OAuth 2.0协议,使得身份验证和授权变得更加安全和直观。JOpenID可能包含了对OpenID Connect的支持,允许开发者获取...
OpenID认证通常涉及三个角色:用户(也称为声称者)、身份提供者(Identity Provider, IDP)和依赖方(Relying Party, RP)。当用户尝试登录依赖方网站时,网站会重定向用户到其选择的身份提供者进行身份验证。一旦...
因为:首先Azure Active Directory提供了OAuth2.0、OpenId Connect 1.0、SAML和WS-Federation 1.2标准协议接口;其次微软在ASP.NET 5中移植了集成OpenId Connect的OWIN中间件。所以,只要在ASP.NET 5项目中引用”...
2. **JOIDS服务器架构**:JOIDS是用Java语言编写的,遵循OpenID规范,支持OpenID 2.0协议。其核心组件包括认证服务器、用户接口、配置管理和扩展功能。它允许开发者自定义认证策略,支持多种认证方式,如用户名和...
**OpenID Connect (OIDC)** 是一个身份层协议,它建立在OAuth 2.0之上,提供了一种简单的方式来验证用户身份。OIDC允许服务提供商(如网站或应用)通过与身份提供商(Identity Provider, IDP)交互,验证用户的登录...
【标题】"openid-connect-common-1.0.14.zip" 涉及的是OpenID Connect协议的一个常见实现,这是OAuth 2.0协议的扩展,主要用于身份验证。OpenID Connect Common库通常包含了处理OpenID Connect流程的核心组件,如...
它支持各种身份验证协议,例如SAML 2.0 Web SSO,OpenID,OAuth 2.0 / 1.0a,OpenID Connect和WS-Federation Passive。 它通过XACML 2.0 / 3.0支持基于角色的授权和精细授权,而SCIM支持入站/出站置备。 这基于...
OpenID Connect(OIDC)是一种基于OAuth 2.0协议的身份验证层,它提供了一种简单的方式来安全地验证用户身份。在Rust编程语言中,`openid-connect-rs`是一个库,专门用于实现OpenID Connect的客户端和服务端功能。这...
- **身份提供者(Identity Provider)**:提供OpenID的实体,为每个用户提供一个OpenID。 - **服务提供者(Relying Party)**:支持使用OpenID登录的服务提供商。 - **标识(Identifier)**:用户用于标识自己身份的URL或...