OpenID和OAuth有什么区别？

我真的是想了解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。

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

礼貌的维基百科

OAuth

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

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

OpenID

用于authenticate单一登录身份。OpenID应该做的只是允许OpenID提供者证明您自己是。但是，许多站点使用身份验证来提供授权（但是可以将二者分开）

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

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

• OpenID是由OpenID Foundation控制的开放标准和分散式身份验证协议。
• 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。身份证充当OIDC，芯片充当OAuth。更多示例和表单Wiki

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

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

OAuth适用于委托授权。客户端在提供者处注册，提供者将提供授权令牌，该令牌将被接受以代表用户执行操作。

OAuth当前更适合于授权，因为身份验证后的进一步交互已内置在协议中，但是两种协议都在发展。OpenID及其扩展名可以用于授权，而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键。因此，有些人在应该使用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可以选择的很多方面。例如作用域，端点发现和客户端动态注册。

这使编写代码更加容易，该代码使用户可以在多个身份提供者之间进行选择。

（资源）

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。

（资源）

问题的延伸多于答案，但可能会为上面的出色技术答案增加一些视角。我在许多领域都是经验丰富的程序员，但是对于网络编程却一无所知。现在尝试使用Zend Framework构建基于Web的应用程序。

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

在我所读过的所有关于这两者以及它们之间的区别的所有文章中，直到我看到卡尔·安德森（Karl Anderson）的观察之后，“ OAuth可以用于身份验证，这可以被视为无操作授权”才可以使用我看到任何明确的确认，证明OAuth足以满足我的需求。

实际上，当我去发布此“答案”时（当时还不是会员），我在页面底部苦苦思索地寻找自己的身份。如果我没有OpenID登录名，或者没有关于twitter或facebook的信息，则可以选择使用OpenID登录名，这似乎表明OAuth不足以胜任这项工作。但是后来我打开了另一个窗口，寻找了stackoverflow的一般注册过程-瞧，这里有很多第三方认证选项，包括facebook和twitter。最后，我决定使用我的google ID（这是一个OpenID），正是出于以下原因：我不想授予stackoverflow访问我的朋友列表以及其他任何Facebook喜欢分享其用户的权限-但至少它是这样。

如果有人可以发布信息或信息指针，以支持这种多重的第三部分授权设置，以及您如何处理撤消授权或无法访问其第三方网站的用户，那真是太好了。我还得到的印象是，我的用户名标识了一个唯一的stackoverflow帐户，如果我想设置该帐户，可以通过基本身份验证进行访问，并且还可以通过其他第三方身份验证器访问该帐户（例如，这样我就被视为已登录如果我已登录到google，facebook或twitter中的任何一个，则进入stackoverflow。）。由于此站点正在执行此操作，因此此处的某人可能对该主题有相当不错的见解。:-)

抱歉，这么长的时间，而且是一个问题，而不是一个答案-但是Karl的话使它看起来像是在OAuth和OpenID上线程数量众多的最合适的位置。如果没有找到比我更好的地方了，我事先表示歉意，我确实尝试过。

OpenID证明您是谁。

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

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

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

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

   一个。OAuth 2.o并未明确说明客户端注册将如何进行b。它没有提及关于SP（资源服务器）和客户端应用程序之间的交互的任何信息（例如，Analytics Server提供的数据是资源服务器，而显示该数据的应用程序是客户端）

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

OpenId使用OAuth处理身份验证。

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

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

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

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基础架构（或在OAuth基础架构之上）一起部署。OpenID Connect还使用JSON对象签名和加密（JOSE）规范套件，用于在不同位置携带签名和加密的信息。实际上，具有JOSE功能的OAuth 2.0部署对于定义完全兼容的OpenID Connect系统已经是很长的路要走，两者之间的差异相对较小。但是，这种差异有很大的不同，OpenID Connect通过向OAuth基础添加几个关键组件来设法避免了上面讨论的许多陷阱：[...]

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

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

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

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

OpenID Connect扩展了OAuth 2.0授权协议以用作身份验证协议，因此您可以使用OAuth进行单点登录。OpenID Connect引入了ID令牌的概念，ID令牌是一种安全令牌，可让客户端验证用户的身份

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

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

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

OAuth 2.0具有以下授权类型

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

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

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

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

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

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

OAuth在授权的基础上构建身份验证：用户将对自己身份的访问权限委派给应用程序，然后该应用程序成为身份API的使用者，从而首先找出谁授权了客户端http://oauth.net/文章/身份验证/