OpenID和OAuth有什么区别？

Question

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

Answer 1

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

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

博文“OpenID versus OAuth from the user’s perspective”对用户的角度进行了简单的比较，“OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing”提供了更多相关信息。

Answer 2

有三种方法可以比较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中的身份。但这就是他们共享的一切。

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

Answer 3

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

OAuth旨在授权代表您执行操作，以便stackoverflow.com（或任何地方）可以在不知道您的Twitter密码的情况下自动代表您自行发送Tweet权限。

Answer 4

许多人仍然访问这个，所以这是一个非常简单的图解释

Courtesy Wikipedia

Answer 5

OAuth

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

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

<强>的OpenID

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

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

Answer 6

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

Answer 7

OpenID和OAuth是用于身份验证和/或授权的每个基于HTTP的协议。两者都旨在允许用户执行操作，而无需向客户端或第三方提供身份验证凭据或一揽子权限。虽然它们相似，并且提出了将它们一起使用的标准，但它们是单独的协议。

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

OAuth旨在用于委派授权。客户向提供商注册，提供商将提供授权令牌，代表用户执行操作。

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

Answer 8

我认为有必要重新审视这个问题，正如评论中指出的那样，OpenID Connect的引入可能会带来更多的混乱。

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

Answer 9

解释OpenID，OAuth，OpenID Connect之间的区别：

  

OpenID是OAuth用于身份验证的协议   授权。身份验证是为了确保那个人你   正在谈论的确是他自称的人。授权是关于   决定那个人应该被允许做什么。

     

在OpenID中，委派身份验证：服务器A想要进行身份验证   用户U，但发送了U的凭证（例如U的名称和密码）   另一个服务器B，A信任（至少，信任认证   用户）。实际上，服务器B确保U确实是U，然后告诉   答：“好吧，那是真正的U”。

     

在OAuth中，授权授权：实体A从实体B获取   A可以向服务器S显示授予访问权限的“访问权限”;乙   因此可以在不给出的情况下向A提供临时的特定访问密钥   他们太强大了。您可以将OAuth服务器想象为密钥主服务器   在一个大酒店;他给了员工打开车门的钥匙   他们应该进入的房间，但每个钥匙都是有限的（它   不允许进入所有房间）;此外，钥匙   几个小时后自毁。

     

在某种程度上，授权可能会被滥用   伪认证，假设实体A从B获得   通过OAuth访问密钥，并将其显示给服务器S，然后服务器S可以   在授予访问密钥之前推断B验证了A。所以有些   人们使用OAuth应该使用OpenID。这个架构可能或   可能没有启发;但我认为这种伪认证是   比任何东西都更令人困惑。 OpenID Connect就是这样做的：它滥用了   将OAuth转换为身份验证协议。在酒店比喻：如果我   遇到一个声称的员工，那个人告诉我他有一个   打开我房间的钥匙，然后我想这是一个真正的员工，   在关键主人不会给他一把钥匙的基础上   如果不是，我会打开我的房间。

(source)

  

OpenID Connect与OpenID 2.0有何不同？

     

OpenID Connect执行许多与OpenID 2.0相同的任务，但确实如此   所以这是一种API友好的方式，可以由本机和移动设备使用   应用。 OpenID Connect定义了可靠的可靠机制   签名和加密。而OAuth 1.0a和OpenID的集成   2.0需要扩展，在OpenID Connect中，OAuth 2.0功能与协议本身集成。

(source)

  

OpenID connect将为您提供访问令牌和ID令牌。身份证   token是一个JWT，包含有关经过身份验证的用户的信息。   它由身份提供者签名，可以阅读和验证   无需访问身份提供者。

     

此外，OpenID连接标准化了很多东西   oauth2最终选择。例如范围，端点发现，   并动态注册客户。

     

这使得编写允许用户选择的代码变得更加容易   多个身份提供者。

(source)

Google的OAuth 2.0

  

Google的OAuth 2.0 API可用于身份验证和   授权。本文档介绍了我们的OAuth 2.0实现   用于身份验证，符合OpenID Connect   规范，并通过OpenID认证。文档中找到了   Using OAuth 2.0 to Access Google APIs也适用于此服务。如果   你想以交互方式探索这个协议，我们建议你   Google OAuth 2.0 Playground

(source)

Answer 10

更多问题的扩展而不是答案，但它可能会为上面的重大技术答案增加一些观点。我是一个经验丰富的程序员，涉及多个领域，但总体上是为网络编程的菜鸟。现在尝试使用Zend Framework构建基于Web的应用程序。

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

在我读过的所有文章中我都读过两篇文章以及它们之间的区别，直到我看到Karl Anderson上面的观察结果，“OAuth可以用于身份验证，可以被认为是无操作授权“我看到任何明确的确认OAuth足以满足我的目的。

事实上，当我发布这个“回答”，当时不是会员时，我在这个页面的底部看了很长时间，以确定自己。如果我没有使用OpenID登录或获取一个，但没有关于Twitter或Facebook的选项，那么使用OpenID登录的选项似乎表明OAuth不适合这项工作。但随后我打开了另一个窗口，寻找了stackoverflow的一般注册过程 - 而且看到有很多第三方认证选项，包括facebook和twitter。最后我决定使用我的谷歌ID（这是一个OpenID），正是因为我不想授予我朋友列表的堆栈溢出访问权以及facebook喜欢分享其用户的任何其他内容 - 但至少它是一个证明OAuth足以满足我的用途。

如果有人可以发布信息或指向有关支持此类多个第三方授权设置的信息，以及您如何处理撤销授权或无法访问其第三方网站的用户，那将真的很棒。我还得到的印象是，我的用户名在这里标识了一个唯一的stackoverflow帐户，如果我想设置它，我可以使用基本身份验证访问该帐户，并通过其他第三方身份验证器访问同一帐户（例如，我将被视为已记录如果我登录到google，facebook或twitter中的任何一个，则进入stackoverflow ...）。由于这个网站正在这样做，这里的某些人可能对这个主题有一些非常好的见解。 ： - ）

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

Answer 11

• OpenID 是由OpenID Foundation控制的开放标准和分散式身份验证协议。
• OAuth 是用于访问委派的开放标准。
• OpenID Connect （OIDC）结合了OpenID和OAuth的功能，即同时进行身份验证和授权。

OpenID 采用由某些“ OpenID提供程序”（即身份提供程序（idP））管理的唯一this question的形式。

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

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

URI

例如，如果您选择使用自己的Google帐户登录 Auth0 ，则使用 OIDC 。成功通过Google身份验证并授权 Auth0 访问您的信息后，Google会将有关用户和所执行的身份验证的信息发送回 Auth0 。此信息以 JSON Web令牌（JWT）返回。您将收到一个访问令牌和一个ID令牌（如果要求）。 ：Types of Token

类比：
一个组织使用 ID卡进行识别，并且包含芯片，它存储有关员工的详细信息以及授权，即园区/门/ ODC访问权限。 身份证充当 OIDC ，芯片充当 OAuth 。 Source: OpenID Connect并形成more examples

Answer 12

OpenID 证明你是谁。

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

Answer 13

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

1. OpenID是Google的专有实现，允许第三方应用程序，如报纸网站，您可以使用谷歌登录和评论文章等其他用例。基本上，没有密码共享到报纸网站。让我在这里提出一个定义，这种方法在企业方法中称为联合。在Federation中，您有一个服务器，您可以在其中进行身份验证和授权（称为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.哦，错过了一个重要的观点，即在此期间，Google感觉到OAuth实际上并没有解决身份验证问题，IDP将如何将用户数据提供给SP（实际上在SAML中实际上很好地解决）以及其他松散的目标，如：

   一个。 OAuth 2.o没有明确说明客户注册将如何发生 湾它没有提到任何关于SP（资源服务器）和客户端应用程序之间的交互（比如提供数据的Analytics Server是资源服务器和显示数据是客户端的应用程序）

在技术上已经有了很好的答案，我想到给出简要的进化观点

Answer 14

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

通过类比，它就像.NET依赖于Windows API。您可以直接调用Windows API，但它是如此广泛，复杂和方法论据如此庞大，您可能很容易犯错误/错误/安全问题。

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

Answer 15

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

  

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系统的一个很长的路，并且两者之间的增量相对较小。但是这个delta有很大的不同，OpenID Connect通过向OAuth基础添加几个关键组件来设法避免上面讨论的许多陷阱：[...]

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

Answer 16

创建这两个协议的原因有所不同。创建OAuth是为了授权第三方访问资源。 OpenID的创建是为了执行分散式身份验证。 website声明以下内容：

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

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

Answer 17

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

按照定义，身份验证会回答两个问题。

1. 用户是谁？
2. 该用户当前在系统上吗？

OAuth 2.0具有以下授予类型

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

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

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

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

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

如果您希望进行身份验证，则可以使用OpenID Connect，它除了提供access_token之外还提供了一个“ id_token”，它可以回答每个身份验证协议都必须回答的问题。

Answer 18

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

Answer 19

OpenId -仅用于身份验证。

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

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

Answer 20

我已经阅读了很多有关此主题的文章，并且发现下面的链接对于区分OpenId和OAuth非常有用。基本上，我们需要了解 id_token 和 access_token 之间的区别。这将有助于区分 OpenId身份验证和 OAuth授权。

我的结论：

id_token = JWT Token

access_token = GUID string

https://nhsconnect.github.io/national-authentication/TechOverview_Artefacts.html#:~:text=A%20JSON%20Web%20Token%20(JWT,used%20during%20the%20authentication%20service.&text=An%20access%20tokens%20is%20a%20credential%20used%20to%20access%20protected%20resources.


https://www.youtube.com/watch?v=BdKmZ7mPNns

Youtube link OpenId time start: 08:10

希望这个好帮助。

Answer 21

OAuth在授权之上构建身份验证：用户将对其身份的访问权委托给应用程序，然后该应用程序成为身份API的使用者，从而找出首先授权客户端的人http://oauth.net/articles/authentication/