OpenID和OAuth有什么区别？

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

325006 次浏览
小开

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

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

小开
最佳答案

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

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

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

小开

OAuth

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

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

OpenID

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

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

小开

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

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

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

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

小开

与其说是答案，不如说是对问题的扩展，但它可能会为上面的伟大技术答案增加一些视角。我在许多领域都是一名经验丰富的程序员，但在网络编程方面完全是新手。现在正在尝试使用Zend Framework构建一个基于Web的应用程序。

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

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

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

如果有人可以发布信息或指向有关支持这种多重第三方授权设置的信息的指针，以及如何处理撤销授权或失去对其第三方网站的访问权限的用户，那真是太好了。我还得到的印象是，我的用户名在这里标识了一个独特的stackoverflow帐户，如果我想设置它，我可以使用基本身份验证访问该帐户，并通过其他第三方身份验证器访问相同的帐户（例如，如果我登录到任何谷歌，Facebook或Twitter，我将被视为登录到stackoverflow…）。由于这个网站正在这样做，这里的人可能对这个问题有一些很好的见解。：-）

对不起，这太长了，与其说是一个答案，不如说是一个问题——但是卡尔的话让它看起来像是在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中，授权访问他们的身份。但这就是它们共享的全部。

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

小开

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

小开

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

OpenID_vs_pseudo-authentication_using_OAuth

由维基百科提供

小开

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

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

小开

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

小开

OpenID证明你是谁。

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

小开

关于OpenID、OAuth、OpenID Connect区别的解释：

OpenID是用于身份验证的协议，而OAuth是用于身份验证的协议授权。认证是为了确保你的那个人确实是他自称的人。授权是关于#36825；的人应该被允许做什么？

在OpenID中，身份验证被委托：服务器A想要进行身份验证用户U，但U的凭据（例如U的名称和密码）被发送到A信任的另一个服务器B（至少，信任用于身份验证）事实上，服务器B确保U确实是U，然后告诉对A：“好的，这是真正的U”。

在OAuth中，授权被委托：实体A从实体B获得A可以向服务器S显示被授予访问权限的“访问权限”；B因此，可以向A提供临时的、特定的访问密钥，而不会给出他们太强大了。您可以将OAuth服务器想象为密钥管理员在一家大旅馆里；他给员工钥匙，打开酒店的门他们应该进入的房间，但每个关键是有限的（它不允许访问所有房间）；此外，钥匙几个小时后自毁。

在某种程度上，授权可能会被滥用到某些伪认证，基于如果实体A从B获得通过OAuth访问密钥，并将其显示给服务器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连接将为您提供一个访问令牌和一个id令牌。id令牌是一个JWT，包含有关经过身份验证的用户的信息。它由身份提供者签名，可以读取和验证没有访问身份提供者。

此外，OpenID连接标准化了很多事情oAuth2留给选择。例如范围、端点发现、和客户端的动态注册。

这使得编写允许用户在多个身份提供者。

（来源）

Google的OAuth 2.0

Google的OAuth 2.0 API可用于身份验证和授权。本文档描述了我们的OAuth 2.0实现用于身份验证，符合OpenID Connect规范，并通过OpenID认证。留档在使用OAuth 2.0访问Google API也适用于此服务。如果你想交互式地探索这个协议，我们建议Google OAuth 2.0 Playground.

（来源）

小开

我目前正在开发OAuth 2.0和OpenID连接规范。所以这是我的理解：之前是：

  1. OpenID是谷歌的专有实现，允许第三方应用程序，如报纸网站，你可以使用谷歌登录并评论一篇文章等其他用途。所以本质上，报纸网站没有密码共享。让我在这里提出一个定义，这种企业方法称为联合。在联合中，你有一个服务器，在那里你进行身份验证和授权（称为IDP，身份提供者），通常是用户凭证的保管者。你有业务的客户端应用程序称为SP或服务提供者。如果我们回到同一个报纸网站的例子，那么报纸网站在这里是SP，谷歌是IDP。在企业中，这个问题很早就用SAML解决了。当时XML用来统治软件行业。所以从Web服务到配置，所有东西都使用XML，所以我们有了SAML，一个完整的联邦协议

  2. OAuth：OAuth看到它作为一种标准出现，关注所有这些专有方法，所以我们将OAuth 1. o作为标准，但只解决授权问题。没有多少人注意到，但它开始流行起来。然后我们在2012年有了OAuth 2.0。随着世界转向云计算，计算设备转向移动和其他此类设备，首席技术官和架构师真正开始关注OAuth。OAuth被视为解决软件客户可能向一家公司提供IDP服务，并从salesforce、SAP等不同供应商提供许多服务的主要问题。所以这里的集成看起来真的像联邦场景有点大问题，使用SAML是昂贵的，所以让我们探索OAuth 2. o.哦，错过了一个重要的观点，在这段时间里，谷歌感觉到OAuth实际上没有解决身份验证，IDP将如何将用户数据提供给SP（实际上在SAML中得到了很好的解决）以及其他松散的结束，如：

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

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

小开

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

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

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

小开

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

OAuth：在授予某些功能访问权限之前，必须进行身份验证，对吧？。所以OAuth=OpenId做什么+授予对某些功能的访问权限？-Hassan Makarov June 21 at 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的即席扩展相反）。

小开
  • OpenID是由OpenID基金会控制的开放标准和去中心化身份验证协议。
  • OAuth是用于访问委托的开放标准。
  • OpenID Connect（OIDC）结合了OpenID和OAuth的功能，即同时进行身份验证和授权。

OpenID采用由某个“OpenID提供者”（即身份提供者（idP））管理的唯一URI的形式。

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

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

输入图片描述

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

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

小开

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

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

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

小开

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是巧克力，饼干、TLS基础设施、身份提供者是提供“身份验证”功能所需的其他成分。

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

小开

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

小开

OpenId-仅用于身份验证。

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

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

小开

阅读并做了一些工作后，我想到了我需要知道的事情，这些是：OpenID Connect、OAuth、JWT和SAML。

我会给一个总结，它可能会帮助某人：

OpenID连接（OIDC）：如果我们可以使用Google帐户登录网站，那么您使用的是OIDC。

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

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

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看起来会成为赢家。

OpenID Connect（OIDC）与SAML：主要区别：

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

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

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

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

想要更多OpenID vs SAML？阅读下面：https://www.onelogin.com/blog/real-difference-saml-oidchttps://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/

小开

现在OpenID连接是最相关的，所以我将解释OpenID连接和OAuth 2之间的区别。

OpenID连接指定IDToken标准：https://openid.net/specs/openid-connect-core-1_0.html#IDToken

这是OpenID连接的主要贡献。因此，它指定了身份验证完成后响应中应该包含的内容。

IDToken需要是JWT令牌，并包含用户的信息，例如用户ID、用户名等。返回的信息取决于授权时传递的声明。它还包含令牌的到期日期，它应该包含令牌的数字签名。此签名用于使用公钥验证令牌。

第二个重大区别与公钥有关。OpenID连接使用称为发现或众所周知的端点的东西。它是一个公开开放的端点，只是重新运行带有公钥和授权端点等值的JSON。

https://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedDiscovery

因此，本质上OpenID与authentication相关，因为它指定了IDToken，这是通过检查IDToken的数字签名和到期日期来验证用户身份所必需的。

OAuth处理authorization，特别是与范围和验证资源服务器上的访问令牌相关的。

但是，正如这里所写的，OpenID使用OAuth 2授权进行身份验证。

https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

身份验证请求是OAuth 2.0授权请求，请求终端用户通过授权服务器进行身份验证。


提交答案