1073

我真的想了解 OpenID 和 OAuth 之间的区别？也许它们是两个完全不同的东西？

4

21 回答 21

910

OpenID是关于身份验证（即证明你是谁），OAuth是关于授权（即授予对功能/数据/等的访问权限，而无需处理原始身份验证）。

OAuth 可用于外部合作伙伴站点，以允许访问受保护的数据，而无需重新对用户进行身份验证。

博客文章“从用户的角度看 OpenID 与 OAuth”从用户的角度对两者进行了简单比较，“ OAuth-OpenID：如果你认为它们是同一件事，你就大错特错了”有更多信息关于它。

于 2009-07-06T13:47:07.407 回答
397

比较 OAuth 和 OpenID 的方式有以下三种：

一、目的

OpenID 是为联合身份验证而创建的，也就是说，让第三方通过使用他们已经拥有的帐户为您验证您的用户。联合一词在这里很重要，因为 OpenID 的全部意义在于可以使用任何提供者（白名单除外）。您无需预先选择或与提供商协商交易以允许用户使用他们拥有的任何其他帐户。

创建 OAuth 是为了消除用户与第三方应用程序共享密码的需要。它实际上是作为解决 OpenID 问题的一种方式开始的：如果您的站点支持 OpenID，则不能使用 HTTP 基本凭据（用户名和密码）来提供 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 中，用户授权访问他们的身份。但这就是他们分享的全部。

每个协议都有不同的计算签名的方式来验证请求或响应的真实性，并且每个协议都有不同的注册要求。

于 2011-08-02T16:37:41.117 回答
119

OpenID（主要）用于识别/身份验证，因此stackoverflow.com知道我拥有chris.boyle.name（或任何地方），因此我可能是chris.boyle.name昨天拥有并获得一些声誉积分的同一个人。

OAuth 旨在授权代表您采取行动，以便stackoverflow.com（或在任何地方）可以自动请求许可，例如代表您发推文，而无需知道您的 Twitter 密码。

于 2009-07-06T13:45:08.033 回答
106

许多人仍然访问它，所以这里有一个非常简单的图表来解释它

OpenID_vs._pseudo-authentication_using_OAuth

礼貌维基百科

于 2014-05-19T08:37:59.807 回答
46

身份验证

仅用于委托authorization- 意味着您授权第三方服务访问使用个人数据，而无需提供密码。OAuth“会​​话”通常比用户会话寿命更长。这意味着 OAuth 旨在允许授权

即 Flickr 使用 OAuth 允许第三方服务代表他们发布和编辑个人图片，而无需他们提供他们的闪烁用户名和密码。

开放ID

用于authenticate单点登录身份。所有 OpenID 应该做的是允许 OpenID 提供者证明你说你是。但是很多站点使用身份认证来提供授权（但是两者可以分开）

即一个人在机场出示他们的护照以验证（或证明）他们使用的机票上的名字是他们。

于 2009-07-06T20:15:33.220 回答
37
  • OpenID是由 OpenID 基金会控制的开放标准和去中心化身份验证协议。
  • OAuth是访问授权的开放标准。
  • OpenID Connect (OIDC) 结合了 OpenID 和 OAuth 的功能，即同时进行身份验证和授权。

OpenID采用由一些“OpenID 提供者”即身份提供者 (idP) 管理的唯一URI的形式。

OAuth可以与 XACML 结合使用，其中 OAuth 用于所有权同意和访问委托，而 XACML 用于定义授权策略。

OIDC使用简单的 JSON Web 令牌 (JWT)，您可以使用符合OAuth 2.0规范的流来获取它。OAuth与OIDC直接相关，因为OIDC是构建在OAuth 2.0之上的身份验证层。

在此处输入图像描述

例如，如果您选择使用您的 Google 帐户登录到Auth0，那么您使用的是 OIDC。在您成功通过 Google 进行身份验证并授权Auth0访问您的信息后，Google 将向Auth0发送有关用户和所执行身份验证的信息。此信息以JSON Web 令牌(JWT) 的形式返回。您将收到一个访问令牌，如果需要，您将收到一个 ID 令牌。令牌类型：来源：OpenID Connect

类比：
一个组织使用ID卡进行识别，它包含芯片，它存储有关员工的详细信息以及授权，即校园/门/ODC 访问。ID卡充当OIDC，芯片充当OAuth。更多示例并形成wiki

于 2018-07-26T01:38:34.937 回答
34

如果您的用户可能只想使用 Facebook 或 Twitter 登录，请使用 OAuth。如果您的用户是运行他们自己的 OpenID 提供者的脖子胡须，因为他们“不希望任何其他人拥有他们的身份”，请使用 OpenID。

于 2012-03-20T19:37:06.940 回答
22

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钥匙。所以有些人在他们应该使用 OpenID 的地方使用 OAuth。这种模式可能有启发性，也可能没有启发性；但我认为这种伪身份验证比任何事情都更令人困惑。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 connect 标准化了很多 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。

（来源）

于 2016-10-30T20:38:49.317 回答
21

OpenID 和 OAuth 都是基于 HTTP 的身份验证和/或授权协议。两者都旨在允许用户在不向客户端或第三方提供身份验证凭据或全面权限的情况下执行操作。虽然它们相似，并且有提议的标准将它们一起使用，但它们是单独的协议。

OpenID 用于联合身份验证。客户端接受来自任何提供者的身份声明（尽管客户端可以自由地将提供者列入白名单或黑名单）。

OAuth 用于委托授权。客户端向提供者注册，提供者提供授权令牌，它将接受这些令牌代表用户执行操作。

OAuth 目前更适合授权，因为身份验证后的进一步交互内置于协议中，但两种协议都在发展。OpenID 及其扩展可用于授权，OAuth 可用于身份验证，可以认为是无操作授权。

于 2009-08-27T23:27:06.807 回答
15

我相信重新审视这个问题是有道理的，正如评论中也指出的那样，OpenID Connect 的引入可能带来了更多的混乱。

OpenID Connect 是一种类似于 OpenID 1.0/2.0 的身份验证协议，但它实际上构建在 OAuth 2.0 之上，因此您将获得授权功能以及身份验证功能。这篇（相对较新但重要的）文章很好地解释了两者之间的区别：http: //oauth.net/articles/authentication/

于 2015-01-12T11:18:56.067 回答
11

更多的是对问题的扩展而不是答案，但它可能会为上述出色的技术答案增加一些视角。我是多个领域的经验丰富的程序员，但对 Web 编程完全是菜鸟。现在尝试使用 Zend Framework 构建基于 Web 的应用程序。

肯定会实现一个特定于应用程序的基本用户名/密码身份验证接口，但要认识到，对于越来越多的用户来说，另一个用户名和密码的想法是一种威慑。虽然不完全是社交网络，但我知道该应用程序的很大一部分潜在用户已经拥有 facebook 或 twitter 帐户。该应用程序并不真正想要或不需要从这些站点访问有关用户帐户的信息，它只是想提供一种便利，即如果用户不想设置新的帐户凭据，则不需要。从功能的角度来看，这似乎是 OpenID 的典型代表。但似乎 facebook 和 twitter 本身都不是 OpenID 提供者，尽管它们确实支持 OAuth 身份验证来访问其用户的数据。

在我读过的所有关于这两者以及它们有何不同的文章中，直到我看到上面 Karl Anderson 的观察，“OAuth 可以用于身份验证，这可以被认为是一种无操作授权”我看到任何明确确认 OAuth 对于我想做的事情来说已经足够好了。

事实上，当我去发布这个“答案”时，当时我还不是会员，我在这个页面的底部寻找了很长时间来识别自己的选项。如果我没有使用 OpenID 登录或获取一个，但没有关于 twitter 或 facebook 的选项，似乎表明 OAuth 不足以完成这项工作。但随后我打开了另一个窗口并查找了 stackoverflow 的一般注册过程——你瞧，有许多 3rd 方身份验证选项，包括 facebook 和 twitter。最后，我决定使用我的 google id（它是一个 OpenID），正是因为我不想授予 stackoverflow 访问我的朋友列表以及 facebook 喜欢分享的有关其用户的任何其他内容的权限——但至少它是

如果有人可以发布信息或指向有关支持这种多第 3 部分授权设置的信息，以及您如何处理撤销授权或无法访问其第 3 方站点的用户，那将是非常棒的。我还觉得我的用户名在这里标识了一个唯一的 stackoverflow 帐户，如果我想设置它，我可以通过基本身份验证访问该帐户，并且还可以通过其他 3rd 方身份验证器访问同一个帐户（例如，这样我就会被视为已登录如果我登录到任何谷歌、脸书或推特...）。由于这个网站正在这样做，所以这里的某个人可能对这个主题有一些很好的洞察力。:-)

抱歉，这太长了，更像是一个问题而不是一个答案——但 Karl 的评论使它看起来像是在 OAuth 和 OpenID 上的大量线程中发布的最合适的地方。如果我没有找到更好的地方，我提前道歉，我确实尝试过。

于 2010-10-06T06:41:36.980 回答
4

OpenID证明了你是谁。

OAuth授予对授权方提供的功能的访问权限。

于 2015-12-26T11:41:38.140 回答
3

我目前正在研究 OAuth 2.0 和 OpenID 连接规范。所以这是我的理解：早些时候他们是：

  1. OpenID 是 Google 的专有实现，允许第三方应用程序，例如报纸网站，您可以使用 google 登录并评论文章等其他用例。所以本质上，没有与报纸网站共享密码。让我在这里提出一个定义，企业方法中的这种方法称为联合。在联邦中，您有一个服务器，您可以在其中进行身份验证和授权（称为 IDP，身份提供者），通常是用户凭据的保管者。您开展业务的客户端应用程序称为 SP 或服务提供商。如果我们回到同一个报纸网站的例子，那么这里的报纸网站是 SP，而 Google 是 IDP。在企业中，此问题较早使用 SAML 解决。那个时候 XML 曾经统治着软件行业。所以从 web 服务到配置，一切都过去了 XML，所以我们有了 SAML，

  2. OAuth：OAuth 将其视为一种标准，着眼于所有这些专有方法，因此我们将 OAuth 1.o 作为标准，但仅解决授权问题。没有多少人注意到，但它开始回升。然后我们在 2012 年推出了 OAuth 2.0。随着世界向云计算发展以及计算设备向移动设备和其他此类设备移动，CTO、架构师真正开始关注。OAuth 被视为解决了软件客户可能向一家公司提供 IDP 服务并拥有来自不同供应商（如 salesforce、SAP 等）的许多服务的主要问题。因此，这里的集成确实看起来像联邦场景有点大问题，使用 SAML 成本高昂因此，让我们探索 OAuth 2.o。哦，错过了重要的一点，在这段时间里，谷歌感觉到 OAuth 实际上没有

    一种。OAuth 2.o 没有明确说明客户端注册将如何发生 b. 它没有提及 SP（资源服务器）和客户端应用程序之间的交互（例如提供数据的分析服务器是资源服务器，而显示该数据的应用程序是客户端）

这里已经给出了技术上很好的答案，我想给出一个简短的进化观点

于 2017-03-16T19:16:42.983 回答
2

在阅读并做了一些工作之后，我想出了我需要知道的东西，这些是：OpenID Connect、OAuth、JWT 和 SAML。

我会做一个总结，它可能对某人有帮助：

Openid connect(OIDC)：如果我们可以使用 google 帐户登录网站，那么您使用的是 OIDC。

OAuth：一个应用程序想要访问我的 facebook 联系人列表并代表我做一些事情。如果我授权此应用程序，那么我可能正在使用 OAuth。

JWT：OAuth 使用 JWT、JWT（JSON Web Tokens）——它只是一种令牌格式。JWT 令牌是 JSON 编码的数据结构，包含有关发行者、主题（声明）、到期时间等信息。它经过签名以防篡改和真实性，并且可以使用对称或非对称方法对其进行加密以保护令牌信息。JWT 比 SAML 1.1/2.0 更简单，所有设备都支持它，它比 SWT（Simple Web Token）更强大。

OAuth 中的授权流程：

OAuth 2.0 协议提供了多个用于授权用户和获取访问令牌的工作流程。这取决于客户端的类型和架构，哪个流程最合适。

以下是 2 个最常用的授权流程：

  1. 授权码：适用于包含客户端和服务器组件的第三方网站。
  • 用户将凭据输入到安全登录网页。
  • 登录后，浏览器被重定向到一个特殊的 URL（由客户端定义），在 URL 中传递一个授权码。
  • 第三方服务器使用授权码在后台通过另一个 HTTP 请求获取访问令牌。来自https://developers.video.ibm.com/api-basics-authentication/
  • 注意：如果您有前端应用程序并且服务器在浏览器中设置了 cookie，那么您的浏览器中已经有 cookie 并且可以访问该网站。
  1. 客户端凭据：开发服务器端应用程序以管理其内容或设置的用户的最佳选择。

IBM 在这里有一个很好的指南：https ://developers.video.ibm.com/api-basics-authentication 要了解所有其他流程的优缺点：这里：https ://www.geeksforgeeks.org/workflow-of- oauth-2-0/

SAML：也用作openid 的替代品，但它是基于 xml 的。因为开发人员发现 OIDC 更容易使用并且更灵活（例如使用移动应用程序比基于 xml 的 SAML 更容易），OIDC 看起来将成为赢家。

Opnid connect vs saml：有主要区别：

  1. SAML 以 XML 格式传输用户数据。OIDC 以 JSON 格式传输用户数据。

  2. SAML 调用它发送 SAML 断言的用户数据。OIDC 调用数据声明。

  3. SAML 调用用户尝试进入服务提供者的应用程序或系统。OIDC 将其称为依赖方。

  4. SAML 是旧的，有更多的功能，但 Openid 越来越受欢迎，因为它比基于 XML 的 SAML 更容易实现，更容易使用但并非所有身份提供者都支持 openid 或 SAML，如果您要集成的身份提供者仅支持 SAML，那么你别无选择。

想要更多 openid 与 SAML？参见下文：

https://www.onelogin.com/blog/real-difference-saml-oidc

https://auth0.com/intro-to-iam/saml-vs-openid-connect-oidc/

想要更多？您可以阅读此 Oauth 和 openid 类比：

http://cakebaker.42dh.com/2008/04/01/openid-versus-oauth-from-the-users-perspective/

于 2021-11-23T21:33:27.703 回答
1

我想解决这个问题的一个特定方面，如此评论中所述：

OAuth：在授予对某些功能的访问权限之前，必须进行身份验证，对吗？所以 OAuth = OpenId 做什么 + 授予对某些功能的访问权限？– 哈桑·马卡罗夫 6 月 21 日 1:57

是的……不。答案很微妙，所以请耐心等待。

当 OAuth 流将您重定向到目标服务（即 OAuth 提供者）时，您可能需要先对该服务进行身份验证，然后才能将令牌交回客户端应用程序/服务。然后，生成的令牌允许客户端应用程序代表给定用户发出请求。

注意最后一句话的一般性：具体来说，我写的是“代表给定用户”，而不是“代表你”。假设“具有与给定用户拥有的资源交互的能力”意味着“您和目标资源的所有者是同一个”，这是一个常见的错误。

不要犯这个错误。

虽然您确实通过 OAuth 提供者进行了身份验证（例如，通过用户名和密码，或者可能是 SSL 客户端证书，或其他方式），但客户端获得的回报不一定被视为身份证明。一个示例是一个流程，其中对另一个用户的资源的访问权被委托给您（并通过代理，OAuth 客户端）。授权并不意味着身份验证。

要处理身份验证，您可能需要查看 OpenID Connect，它本质上是 OAuth 2.0 设置的基础之上的另一层。这是一个引用（在我看来）关于 OpenID Connect 最突出的点（来自https://oauth.net/articles/authentication/）：

OpenID Connect 是 2014 年初发布的开放标准，它定义了一种使用 OAuth 2.0 执行用户身份验证的互操作方式。从本质上讲，它是一种广泛发布的巧克力软糖配方，已被众多专家尝试和测试过。应用程序无需为每个潜在的身份提供者构建不同的协议，而是可以将一个协议与他们想要使用的尽可能多的提供者对话。由于它是一个开放标准，任何人都可以实施 OpenID Connect，而不受限制或知识产权问题。

OpenID Connect 直接构建在 OAuth 2.0 之上，并且在大多数情况下与 OAuth 基础架构一起（或在其之上）部署。OpenID Connect 还使用 JSON 对象签名和加密 (JOSE) 规范套件在不同的地方携带签名和加密的信息。事实上，一个具有 JOSE 能力的 OAuth 2.0 部署对于定义一个完全兼容的 OpenID Connect 系统已经有很长的路要走，两者之间的差异相对较小。但是这个增量有很大的不同，OpenID Connect 设法通过向 OAuth 基础添加几个关键组件来避免上面讨论的许多陷阱：[...]

然后，该文档继续描述（除其他外）令牌 ID 和 UserInfo 端点。前者提供了一组声明（你是谁，令牌何时发行等，可能还有一个签名，通过已发布的公钥验证令牌的真实性，而无需询问上游服务），后者提供了一个例如，以标准化方式询问用户的名字/姓氏、电子邮件和类似信息的方式（与人们在 OpenID Connect 标准化事物之前使用的 OAuth 的临时扩展相反）。

于 2017-08-31T19:46:59.217 回答
1

OAuth 向您返回访问令牌以从资源服务器访问资源，OpenID 向您返回有关 JWT / 加密令牌中资源的元数据详细信息

于 2020-06-11T15:33:28.380 回答
1

OpenId - 仅用于身份验证。

OAuth - 用于身份验证和授权。授权取决于作为 JWT 令牌一部分的 access_token。它可以包含用户权限的详细信息或任何有用的信息。

两者都可以依赖维护其帐户的第 3 方身份验证提供商。例如 OKTA 身份提供者，用户在 OKTA 登录页面上提供凭据，成功登录后，用户将被重定向到消费者应用程序，并在标头中使用 JWT 令牌。

于 2020-07-03T04:13:22.943 回答
0

OpenId 使用 OAuth 来处理身份验证。

以此类推，就像 .NET 依赖于 Windows API。您可以直接调用 Windows API，但它是如此广泛、复杂且方法参数如此庞大，您很容易犯错误/错误/安全问题。

与 OpenId/OAuth 相同。OpenId 依赖 OAuth 来管理身份验证，但定义了特定的令牌 (Id_token)、数字签名和特定的流程。

于 2017-08-27T12:52:23.257 回答
0

这两种协议都是出于不同的原因而创建的。创建 OAuth 是为了授权第三方访问资源。创建 OpenID 是为了执行分散的身份验证。本网站声明如下：

OAuth 是一种旨在验证最终用户身份并向第三方授予权限的协议。此验证产生一个令牌。第三方可以使用此令牌代表用户访问资源。令牌有一个范围。范围用于验证用户是否可以访问资源

OpenID 是一种用于去中心化身份验证的协议。身份验证是关于身份的；建立用户其实就是他自称的那个人。去中心化意味着该服务不知道需要保护的任何资源或应用程序的存在。这是 OAuth 和 OpenID 之间的主要区别。

于 2018-11-05T19:48:14.403 回答
-2

OAuth 2.0 是一种安全协议。它既不是身份验证也不是授权协议。

根据定义，身份验证回答了两个问题。

  1. 用户是谁？
  2. 用户当前是否存在于系统中？

OAuth 2.0 具有以下授权类型

  • client_credentials：当一个应用程序需要与另一个应用程序交互并修改多个用户的数据时。
  • 授权码：用户委托授权服务器发出访问令牌，客户端可以使用该令牌访问受保护的资源
  • refresh_token：当 access_token 过期时，可以利用刷新令牌来获取新的 access_token
  • 密码：用户将其登录凭据提供给调用授权服务器并接收 access_token 的客户端

所有 4 个都有一个共同点，access_token，一个可用于访问受保护资源的工件。

access_token 不提供“身份验证”协议必须回答的 2 个问题的答案。

解释 Oauth 2.0的示例（来源：OAuth 2 in Action，Manning 出版物）

让我们谈谈巧克力。我们可以用巧克力制作许多甜点，包括软糖、冰淇淋和蛋糕。但是，这些都不能等同于巧克力，因为制作糖果需要多种其他成分，例如奶油和面包，尽管巧克力听起来像是主要成分。同样，OAuth 2.0 是巧克力，cookie、TLS 基础设施、身份提供者是提供“身份验证”功能所需的其他成分。

如果你想要身份验证，你可以选择 OpenID Connect，它提供了一个“id_token”，除了一个 access_token，它回答了每个身份验证协议必须回答的问题。

于 2019-01-22T08:44:57.027 回答
-5

OAuth 在授权之上构建身份验证：用户将对其身份的访问委托给应用程序，然后应用程序成为身份 API 的消费者，从而首先找出是谁授权了客户端http://oauth.net/文章/认证/

于 2015-10-23T17:58:29.937 回答