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
分享到:
相关推荐
议程和幻灯片内容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. ...
Solving Identity Management in Modern Applications: Demystifying OAuth 2.0, OpenID Connect, and SAML 2.0
授权服务器兼容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批准的许可证)的许可。 有关项目文档,请...
因为:首先Azure Active Directory提供了OAuth2.0、OpenId Connect 1.0、SAML和WS-Federation 1.2标准协议接口;其次微软在ASP.NET 5中移植了集成OpenId Connect的OWIN中间件。所以,只要在ASP.NET 5项目中引用”...
它支持各种身份验证协议,例如SAML 2.0 Web SSO,OpenID,OAuth 2.0 / 1.0a,OpenID Connect和WS-Federation Passive。 它通过XACML 2.0 / 3.0支持基于角色的授权和精细授权,而SCIM支持入站/出站置备。 这基于...
ORY Hydra是经过强化,经过OpenID认证的OAuth 2.0服务器和OpenID Connect提供商,针对低延迟,高吞吐量和低资源消耗进行了优化。 ORY Hydra不是身份提供者(用户注册,用户登录,密码重置流程),而是通过连接到您...
ASP.NET Core 2.0附带了Identity系统的另一种重写(在Microsoft.AspNetCore.Identity程序包中),以支持通过OpenID / OAuth进行本地登录和远程登录,但仅与Entity Framework提供程序一起提供(Microsoft。...
用于身份验证插件,实现基于表单,基本,本地,LDAP,OpenID Connect,OAuth 2.0,SAML身份验证。 请查看其他相关插件: 在启用了插件的情况下下载Caddy: 请表示您对这项工作的赞赏,并 :star: :star: :star: 请在...
通过Ocelot API网关支持的... 首先,我们将开发Movies.API项目,并使用IdentityServer4 OAuth 2.0实现保护此API资源。 从IdentityServer4生成带有client_credentials的JWT令牌,并将使用此令牌保护受Movies
它包含了基本的用户、角色、第三方登录、Claim等功能,使用 Identity Server 4 可以为其轻松扩展 OpenId connection 和 Oauth 2.0 相关功能。网上已经有大量相关文章介绍,不过这还不是 Asp.Net Core Identity 的...
dex-联合的OpenID Connect提供程序 Dex是一种身份服务,使用来驱动其他应用程序的身份验证。 Dex通过充当其他身份提供者的门户 这使dex可以将身份验证延迟到LDAP服务器,SAML提供程序或已建立的身份提供程序(如...
OpenID Connect是基于OAuth 2.0协议的简单身份层,它允许计算客户端基于授权服务器执行的身份验证来验证最终用户的身份,以及获取有关最终用户的基本配置文件信息。用户以可互操作且类似于REST的方式使用。 ...
重要更新 从2020年10月1日起,我们成立了一家新。 所有新功能工作都将在我们的新。 新的Duende IdentityServer可通过FOSS(RPL)和商业许可获得。 开发和测试始终是免费的。 我们以获取更多信息。...
重要]已弃用-请参阅MSAL 1.0的新示例 MSAL Android预览版通过使用行业标准OAuth2和OpenID Connect提供融合的体验来支持和,从而使您的应用程序能够开始使用。 此样本演示了您的应用程序应经历的所有正常生命周期,...
MaxKey单点登录认证系统,谐音马克思的钥匙寓意是最大钥匙,是业界领先的IAM身份管理和认证产品,支持OAuth 2.x/OpenID Connect、SAML 2.0、JWT、CAS、SCIM等标准协议,提供安全、标准和开放的用户身份管理(IDM)、身份...
OpenId Connect简介(选看) 建造Identity Server 4服务器,客户凭证授予实例 资源所有者密码凭证授予实例 授权码流实例 刷新访问令牌(MVC客户端) 建立Angular客户端(Angular 7,Angular Material,Angular CLI...
验证DWAPI身份提供程序实现了OpenID Connect和OAuth 2.0标准客户端将使用其客户端ID和密码从Identity Server请求访问令牌,然后使用该令牌获得对API的访问权限。 身份服务器身份服务器提供发现文档作为标准端点。 您...