OAUTH，OpenID和OPENID之间的区别用非常简单的术语进行连接？

#1 楼

OpenID是用于身份验证的协议，而OAuth是用于授权的协议。身份验证是关于确保与您交谈的那个人确实是他声称的身份。授权是决定应允许该人做什么。 A信任的服务器B（至少信任用于验证用户的信任）。实际上，服务器B确保U确实是U，然后告诉A：“好，那是真正的U”。 A可以显示给服务器S授予访问权限”。因此，B可以向A传递临时的特定访问密钥，而无需给它们过多的权限。您可以将OAuth服务器想象成一家大型酒店的关键主机。他向员工提供了打开他们应该进入的房间门的钥匙，但是每个钥匙都是有限的（不能访问所有房间）；此外，密钥会在几个小时后自毁。

在某种程度上，如果实体A通过OAuth从B获得访问密钥，则可以将授权滥用为某种伪身份验证，并将其显示给服务器S，然后服务器S可以在授予访问密钥之前推断B认证了A。因此，有些人在应该使用OpenID的地方使用OAuth。这种模式可能有启发性，也可能没有启发性。但我认为这种伪身份验证比任何其他方法都更加令人困惑。 OpenID Connect就是这样做的：它将OAuth滥用到身份验证协议中。在酒店类比中：如果我遇到一个自称的员工，并且那个人告诉我他有一把可以打开我房间的钥匙，那么我认为这是一位真正的员工，因为钥匙主人不会给他钥匙如果他不在的话，这会打开我的房间。

#2 楼

简单术语


OpenID与验证人的身份（身份验证）有关。
OAuth与访问人的物品（授权）有关。 br />
所有这三个选项都可以使一个人将其用户名/密码（或其他凭据）提供给受信任的机构，而不是不那么受信任的应用程序。

更多详细信息

要了解某些内容，请查看其历史。

OpenID和OAuth在并行的轨道上得到了发展，并于2014年并入OpenID Connect。在其整个历史中，OpenID和OAuth允许应用程序使用受信任的权限来处理私人用户凭据。 OpenID让授权机构验证用户的身份，而OAuth让授权机构授予对用户资料的有限访问权限。

OpenID 1.0（2006）使应用程序可以要求权威机构证明最终用户拥有标识（URL）。


应用程序的最终用户：我是史蒂夫·史密斯（Steve A. Smith）。
应用程序授权：这是史蒂夫·史密斯（Steve A. Smith）？
最终用户和权限在说话。 。Smith。

OpenID 2.0（2007）的功能相同，但是增加了第二种身份格式（XRI），并增加了最终用户指定身份和权限的灵活性。 > OpenID Attribute Exchange 1.0（2007）扩展了OpenID 2.0，其方法是让应用程序具有权限来获取和存储最终用户配置文件信息-除了验证最终用户的身份。


最终用户可以app：我是史蒂夫·史密斯。
应用到权威：这是史蒂夫·史密斯吗？哦，如果是的话，还请给我获取他的电子邮件地址和电话号码。

最终用户和授权部门会说话。
应用程序的权限：是的，那就是SteveA。史密斯他的电子邮件是steve@domain.com，电话是123-456-7890。


OAuth 1.0（2010）允许最终用户授予应用程序对第​​三方资源的访问权限，权威拥有的参与方服务器。


面向最终用户的应用：我们想在其他服务器上访问您的图片。
最终用户和权限会说话。
应用程序的权限：这是一个访问令牌。
应用程序到第三方服务器的权限：这是访问令牌，可证明我被允许访问最终用户的图片。 > OAuth 2.0（2012）的功能与OAuth 1.0相同，但具有全新的协议。

OpenID Connect（2014）在单个协议中结合了OpenID 2.0，OpenID Attribute Exchange 1.0和OAuth 2.0的功能。它允许应用程序使用权限...


验证最终用户的身份，
获取最终用户的配置文件信息，并
获得受限访问最终用户的资料。

#3 楼

许多人仍在访问它，所以这里有一个非常简单的图表来说明它



礼貌的维基百科

#4 楼

我们已经有一个图和大量好的数据，因此这里是一个有帮助的示例。

我想向StackOverflow发表评论。 StackOverflow仅在有50名用户的情况下才允许评论。

StackOverflow必须授权此请求（例如，仅当用户> = 50 rep时才允许此请求）。 StackOverflow不会使用OAuth来执行此操作，因为StackOverflow拥有受保护的资源。如果StackOverflow试图代表用户向Facebook发布评论，则它将使用OAuth。相反，StackOverflow将使用本地授权（例如if (user.reputation < 50) throw InsufficientReputationError();）

为了做到这一点，StackOverflow必须首先知道谁在发出请求。换句话说，为了授权请求，它必须首先对请求进行身份验证。

StackOverflow首先检查会话和HTTP标头，以查看是否可以快速验证用户身份（例如，这不是他们的第一个请求）请求），但失败。

让我们假装StackOverflow已决定使用OpenID Connect。这意味着StackOverflow信任身份提供者。这是StackOverflow信任的服务，可以告诉StackOverflow当前用户是谁。在此示例中，我们假设是Google。

StackOverflow现在询问Google当前用户是谁。但是，Google必须首先确保允许StackOverflow知道当前用户是谁。换句话说，Google必须授权StackOverflow。由于Google是受保护资源的所有者，而StackOverflow是受保护资源的所有者，因此我们可以在此处使用OAuth。实际上，OpenID Connect对此具有强制性。

这意味着StackOverflow必须通过Google信任的授权服务器进行身份验证（实际上，也可以是Google，但并非必须如此），并获得访问令牌。它将访问令牌带到Google并询问用户的身份。然后，Google返回用户的身份（在途中对身份签名），然后StackOverflow在知道用户的身份后立即授权该请求。


StackOverflow尝试使用会话cookie验证请求，但失败了。
然后StackOverflow使用OpenID Connect验证了请求。 OAuth
授权服务器对StackOverflow进行了身份验证（可能使用客户端ID和客户端密钥）。另外，作为OAuth工作流程的一部分，授权服务器可能已通过向用户询问用户名来对请求进行身份验证和密码。
此外，用户本人可能会通过响应授予屏幕来授权SO的身份请求（例如“您是否希望StackOverflow能够访问您的电子邮件？”）。
StackOverflow已授权ensu的要求让用户拥有> 50的声誉。

什么是OpenID（无连接）？

这是一种较早的协议，允许身份提供者（如Google）通过用户服务信息（如StackOverflow）。但是，它为Google使用了另一种方法（不是OAuth）来授权允许StackOverflow访问用户的身份。 OpenID有一些安全漏洞（我认为已解决），但我认为真正的杀手simply是事实是OAuth具有更好的支持，因此比学习OpenID的自定义协议的工作量更少。

今天的每个人都放弃了它。不要使用它。使用OpenID Connect。

“滥用” OAuth

在上述情况下，OAuth完全按照授权使用。但是，还有另一个工作流程通常会使人们感到困惑。之所以出现这种情况，是因为在很多情况下（大多数情况下），提供用户身份的服务器和OAuth授权服务器是同一台服务器。授权服务器获取访问令牌，然后再次访问同一服务器以获取身份令牌。因此，为OAuth规范创建了一个扩展，以允许授权服务器将用户身份信息与访问令牌捆绑在一起。

这允许身份验证完全在浏览器中进行（例如，不需要涉及StackOverflow的服务器） 。但是，这种身份验证的用处较小，并且（我认为？）使用的情况也较少。

#5 楼

除了其他回应之外：我认为很多困惑是由于对身份验证和授权的使用不当或至少是不寻常的使用而已。本身无法处理身份验证。从基本意义上讲，“真实”身份验证（验证用户凭据以证明身份的过程）不在OpenID Connect的范围之内。依赖方可以使用来自第三方ID提供程序的现有身份验证过程，用户数据库和会话处理。在功能上类似于SAML 2.0。

注：严格来说，从依赖方的角度来看，从ID提供商获取和验证ID令牌可以视为一种身份验证方法。我相信这就是“ OpenID Connect是身份验证协议”的来源。


OAuth 2.0作为授权协议的理由相同：通常，授权是定义访问策略的过程，该过程决定了哪些用户可以访问哪些资源。该定义几乎不适用于OAuth。

OAuth 2.0实际上为用户提供了一种允许应用程序/客户端代表他们访问自己的资源的方法。换句话说，OAuth 2.0正在授权客户端应用程序（而非用户）访问资源。在部署OAuth之前，应该已经存在授权策略（允许用户访问资源）。

我应该将OAuth标记为访问委托协议。

#6 楼

如前所述，Oauth是一回事，OpenID是另一回事，而OpenID Connect将两者结合在一起。

但是，正如已经提到的，使用身份验证和授权来区分Oauth和OpenID完全是错误的。身份验证是对实体对存储的身份声明的真实性的确认，归因于OpenID，但它绝对是Oauth流程的一部分。授权（访问特定资源或容器的权限）归功于Oauth，但这绝对是OpenID流程的一部分。

根据我的经验，Oauth和OpenID的真正区别可以从典型的例子中看出。每个方案下正在执行的非身份验证活动以及与谁相关的活动。


OpenID有助于用户访问带有捆绑资源的许可容器（例如，网站访问权限）。
Oauth有助于自动访问容器中的许可资源（例如，文件上的CRUD操作或通过Web api记录）。

OpenID Connect，然后允许用户访问Web地址并一旦进入，将为基础Web应用程序提供一种代表用户检索其他非现场资源的方法。

#7 楼

总结一下：OpenID Connect是一个联合身份API，它包括OAuth 2.0的配置文件和扩展，使客户端（即，移动应用或网站）能够将人员重定向到中央身份提供商以进行身份​​验证，并使该人员可以授权发布有关该客户端的信息。

您应该阅读我的博客OAuth，SAML和OpenID Connect：https：//gluu.co/oauth-saml-openid

OpenID Connect API包括许多与OAuth无关的终结点：

OAuth终结点




授权：提供登录信息的前端渠道网站页面和授权（同意）页面。 （RFC 6749）

令牌：反向通道端点，通常需要身份验证，客户端可以在其中请求访问令牌，id_token和刷新令牌。 （RFC 6749）

配置：在.well-known/openid-configuration发布的提供程序元数据，包括端点的位置，支持的加密算法以及客户端与OP交互所需的其他信息。 （RFC 8414）

客户端注册：创建或更新OAuth客户端的应用程序的端点（RFC 7591）

非OAuth端点



Userinfo：访问令牌保护的API，客户端可以通过该API请求有关主题的声明。这是OAuth术语中的资源服务器。

JWKS：用于签名和加密的OP的当前公钥

会话管理：由所有三个OpenID注销规范使用（ Webfinger：无法引导从电子邮件地址（或其他标识符）向后工作的OP发现，即如何确定域的配置终结点。 （RFC 7033，但不是OAuth WG的一部分）