我真的想了解OpenID和OAuth之间的区别吗？也许他们是两个完全不同的东西？
OpenID是关于身份验证(即证明你是谁),OAuth是关于授权(即授予对功能/数据/等的访问权限而不必处理原始身份验证).
OAuth可以在外部合作伙伴站点中使用,以允许访问受保护的数据,而无需重新验证用户.
从用户的角度来看,博客文章" OpenID与OAuth"从用户的角度对两者进行了简单的比较," OAuth-OpenID:如果你认为他们是同一件事,你就会吵到错误的树 "了解更多信息关于它.
有三种方法可以比较OAuth和OpenID:
1.目的
OpenID是为联合身份验证创建的,即让第三方通过使用已有的帐户为您验证用户身份.联邦这一术语在这里至关重要,因为OpenID的重点在于可以使用任何提供者(白名单除外).您无需预先选择或与提供商协商,以允许用户使用他们拥有的任何其他帐户.
创建OAuth是为了消除用户与第三方应用程序共享密码的需要.它实际上是一种解决OpenID问题的方法:如果您在站点上支持OpenID,则无法使用HTTP Basic凭据(用户名和密码)来提供API,因为用户在您的站点上没有密码.
问题在于OpenID的分离用于身份验证和OAuth的授权是两个协议都可以完成许多相同的事情.它们各自提供了不同实现所需的不同功能集,但基本上它们是可以互换的.两个协议的核心是断言验证方法(OpenID仅限于'这就是我是谁'断言,而OAuth提供了一个'访问令牌',可以通过API交换任何支持的断言).
2.特点
这两种协议都为站点提供了一种方法,可以将用户重定向到其他位置,然后返回可验证的断言.OpenID提供身份断言,而OAuth以访问令牌的形式更通用,然后可用于"询问OAuth提供程序问题".但是,它们各自支持不同的功能:
OpenID - OpenID最重要的特性是它的发现过程.OpenID不需要对要提前使用的每个提供程序进行硬编码.使用发现,用户可以选择要进行身份验证的任何第三方提供商.此发现功能也导致了大多数OpenID的问题,因为它的实现方式是使用HTTP URI作为大多数Web用户无法获得的标识符.OpenID的其他功能是支持使用DH交换进行临时客户端注册,支持优化最终用户体验的即时模式,以及在不向提供商进行另一次往返的情况下验证断言的方法.
OAuth - OAuth最重要的功能是访问令牌,它提供了一种持久的方法来发出额外的请求.与OpenID不同,OAuth不以身份验证结束,而是提供访问令牌以访问由同一第三方服务提供的其他资源.但是,由于OAuth不支持发现,因此需要预先选择并硬编码您决定使用的提供程序.访问您网站的用户不能使用任何标识符,只能使用您预先选择的标识符.此外,OAuth没有身份概念,因此使用它进行登录意味着要么添加自定义参数(由Twitter完成),要么进行另一个API调用以获取当前"登录"用户.
3.技术实施
这两个协议在使用重定向获取用户授权时共享一个共同的体系结构.在OAuth中,用户授权访问其受保护资源和OpenID中的身份.但这就是他们分享的一切.
每种协议都有不同的计算签名的方式,用于验证请求或响应的真实性,每种协议都有不同的注册要求.
OpenID(主要)用于识别/认证,因此stackoverflow.com知道我拥有chris.boyle.name(或在任何地方),因此我可能是chris.boyle.name昨天拥有的同一个人,并获得了一些声望点.
OAuth旨在授权代表您执行操作,以便stackoverflow.com(或在任何地方)可以在不知道您的Twitter密码的情况下自动代表您发送Tweet,例如Tweet.
许多人仍然访问这个,所以这里有一个非常简单的图解释它
礼貌维基百科
OAuth的
authorization仅用于委派- 意味着您授权第三方服务访问以使用个人数据,而无需提供密码.此外,OAuth"会话"通常比用户会话更长寿.意味着OAuth旨在允许授权
即Flickr使用OAuth允许第三方服务代表他们发布和编辑人物图片,而无需提供他们的闪烁用户名和密码.
OpenID的
用于authenticate单点登录身份.所有OpenID应该允许OpenID提供商证明你说你是.然而,许多站点使用身份验证来提供授权(但是两者可以分开)
即一个人在机场出示他们的护照,以验证(或证明)他们正在使用的机票名称是谁.
如果您的用户可能只想使用Facebook或Twitter登录,请使用OAuth.如果您的用户是运行他们自己的OpenID提供商的脖子,因为他们"不希望任何其他人拥有他们的身份",请使用OpenID.
OpenID和OAuth是用于身份验证和/或授权的每个基于HTTP的协议.两者都旨在允许用户执行操作,而无需向客户端或第三方提供身份验证凭据或一揽子权限.虽然它们相似,并且提出了将它们一起使用的标准,但它们是单独的协议.
OpenID旨在用于联合身份验证.客户端接受来自任何提供商的身份断言(尽管客户可以自由列入白名单或黑名单).
OAuth旨在用于委派授权.客户向提供商注册,提供商提供授权令牌,它将接受代表用户执行操作.
OAuth目前更适合授权,因为身份验证后的进一步交互内置于协议中,但这两种协议都在不断发展.OpenID及其扩展可用于授权,OAuth可用于身份验证,可将其视为无操作授权.
一个ID实体(OpenID)和另一个是Auth orization(OAuth),两者都是开放标准.
OpenID Connect(OIDC)是一种基于OAuth 2.0(即O pen Auth orization)系列规范的身份验证协议.它使用简单的JSON Web令牌(JWT),您可以使用符合OAuth 2.0规范的流程获取它.OAuth与OpenID Connect(OIDC)直接相关,因为OIDC是在OAuth 2.0之上构建的身份验证层
虽然OAuth 2.0是关于资源访问和共享即授权,但OIDC是关于用户身份验证的.它的目的是为您提供多个站点的登录.每次您需要使用OIDC登录网站时,您将被重定向到您登录的OpenID站点,然后返回到该网站.
OpenID Connect(OIDC)是OAuth 2.0(授权框架)之上的身份验证层.该标准由OpenID基金会控制:
例如,如果您选择使用Google帐户登录Auth0,则使用OIDC.成功通过Google验证并授权Auth0访问您的信息后,Google会向Auth0发回有关用户和执行身份验证的信息.此信息在JSON Web令牌(JWT)中返回.您将收到一个访问令牌,如果需要,还会收到一个ID令牌.令牌类型:来源:OpenID Connect
类比:
组织使用身份证进行识别,它包含芯片,它存储有关员工的详细信息以及授权,即校园/门/ ODC访问.ID卡充当OIDC,Chip充当OAuth.更多例子
我认为重新审视这个问题也是有道理的,正如评论中指出的那样,OpenID Connect的引入可能会带来更多的混乱.
OpenID Connect是一种身份验证协议,如OpenID 1.0/2.0,但它实际上构建在OAuth 2.0之上,因此您将获得授权功能以及身份验证功能.在这篇(相对较新但很重要的)文章中详细解释了两者之间的差异:http://oauth.net/articles/authentication/
解释OpenID,OAuth,OpenID Connect之间的区别:
OpenID是用于身份验证的协议,而OAuth用于授权.身份验证是为了确保与您交谈的人确实是他声称的人.授权是关于决定应该允许那个人做什么.
在OpenID中,委派认证:服务器A想要认证用户U,但是U的凭证(例如,U的名称和密码)被发送到A信任的另一个服务器B(至少,信任用于认证用户).实际上,服务器B确保U确实是U,然后告诉A:"好吧,那是真正的U".
在OAuth中,授权被委托:实体A从实体B获得A可以向服务器S显示的被授予访问权限的"访问权限"; 因此,B可以向A提供临时的,特定的访问密钥而不会给它们太多的功率.您可以将OAuth服务器想象成一家大酒店的主要服务器; 他给员工钥匙打开他们应该进入房间的门,但每个钥匙都是有限的(它不能进入所有房间); 此外,钥匙在几个小时后自毁.
在某种程度上,授权可以被滥用到一些伪认证中,基于如果实体A通过OAuth从B获得访问密钥,并将其显示给服务器S,则服务器S可以在授予访问权限之前推断B认证A键.所以有些人使用OAuth,他们应该使用OpenID.这种模式可能有启发性,也可能没有启发性; 但我认为这种伪认证比任何事情都更令人困惑.OpenID Connect就是这样做的:它将OAuth滥用到身份验证协议中.在酒店类比:如果我遇到一个声称的员工而且那个人告诉我他有一把钥匙打开我的房间,那么我认为这是一个真正的员工,因为关键主人不会给他一把钥匙如果他没有,我会打开我的房间.
(资源)
OpenID Connect与OpenID 2.0有何不同？
OpenID Connect执行许多与OpenID 2.0相同的任务,但它以API友好的方式执行,并且可由本机和移动应用程序使用.OpenID Connect定义了强大签名和加密的可选机制.虽然OAuth 1.0a和OpenID 2.0的集成需要扩展,但在OpenID Connect中,OAuth 2.0功能与协议本身集成在一起.
(资源)
OpenID connect将为您提供访问令牌和ID令牌.id令牌是JWT,包含有关经过身份验证的用户的信息.它由身份提供者签名,无需访问身份提供者即可读取和验证.
此外,OpenID连接标准化了oauth2可供选择的相当多的东西.例如,范围,端点发现和客户端的动态注册.
这使得编写代码更容易,用户可以在多个身份提供者之间进行选择.
(资源)
谷歌的OAuth 2.0
Google的OAuth 2.0 API可用于身份验证和授权.本文档介绍了我们用于身份验证的OAuth 2.0实现,该实现符合OpenID Connect规范,并且经过OpenID认证.使用OAuth 2.0访问Google API中的文档 也适用于此服务.如果您想以交互方式探索此协议,我们建议您使用 Google OAuth 2.0 Playground.
(资源)
问题的扩展比答案更多,但它可能会为上面的重大技术答案增加一些观点.我是一个经验丰富的程序员,涉及多个领域,但总是为网络编程而努力.现在尝试使用Zend Framework构建基于Web的应用程序.
肯定会实现一个特定于应用程序的基本用户名/密码认证接口,但要认识到,对于越来越多的用户来说,想到另一个用户名和密码是一种威慑.虽然不完全是社交网络,但我知道应用程序的潜在用户中有很大一部分已经拥有Facebook或Twitter帐户.该应用程序并不真的想要或需要从这些网站获取有关用户的帐户信息,它只是希望提供不要求用户建立新的帐户凭据,如果他们不想要的方便.从功能的角度来看,这似乎是OpenID的典型代表.但似乎facebook和twitter都不是OpenID提供商,尽管他们确实支持OAuth身份验证来访问用户的数据.
在所有的文章我读过有关这两个和他们之间的区别,它wan't直到我看到上面的卡尔·安德森的观察,认为"OAuth的可用于身份验证,这可以被看作是一个无操作权限"即我看到任何明确的确认OAuth足以满足我的目的.
事实上,当我发布这个"答案",而不是当时的成员时,我在这个页面的底部看了很长时间,以确定自己.如果我没有使用OpenID登录或获取一个,但没有关于Twitter或Facebook的选项,那么使用OpenID登录的选项似乎表明OAuth不适合这项工作.但后来我打开另一个窗口,并期待为广大注册过程的计算器 - 你瞧还有的第三方身份验证选项,包括Facebook和Twitter摆.最后,我决定用我的谷歌ID(这是一个OpenID)正是出于这个我不想计算器访问给予我的好友列表和其他任何的Facebook之所以喜欢分享有关其用户 - 但至少它"
如果有人可以发布信息或指向有关支持这种多个第三方授权设置的信息,以及如何处理撤销授权或失去对第三方网站的访问权限的用户,那真的很棒.我还得到的印象是,我的用户名在这里标识了一个唯一的stackoverflow帐户,如果我想设置它,我可以使用基本身份验证访问该帐户,并通过其他第三方身份验证器访问同一帐户(例如,我将被视为已记录如果我登录到google,facebook或twitter中的任何一个,则进入stackoverflow ...).由于这个网站正在这样做,这里的某些人可能对这个主题有一些非常好的见解.:-)
对不起,这是一个很长的问题,而不是答案 - 但卡尔的评论使它看起来似乎是最适合在OAuth和OpenID线程中发布的地方.如果有一个我没有找到的更好的地方,我提前道歉,我确实尝试过.
京公网安备 11010802040832号 | 京ICP备19059560号-6 