OpenID was created for federated authentication, that is, letting a third-party authenticate your users for you, by using accounts they already have . 联邦这一术语在这里至关重要，因为OpenID的重点在于可以使用任何提供者（白名单除外） . 您无需预先选择或与提供商协商，以允许用户使用他们拥有的任何其他帐户 .
OAuth was created to remove the need for users to share their passwords with third-party applications . 它实际上是一种解决OpenID问题的方法：如果您在自己的网站上支持OpenID，则可以在您的网站上输入密码 .
这两种协议都为站点提供了一种方法，可以将用户重定向到其他位置，并返回可验证的断言 . OpenID provides an identity assertion while OAuth is more generic in the form of an access token which can then be used to "ask the OAuth provider questions" . 但是，它们各自支持不同的功能：
OpenID - OpenID最重要的特性是它的发现过程 . OpenID不需要对要提前使用的每个提供程序进行硬编码 . 使用发现，用户可以选择要进行身份验证的任何第三方提供商 . 此发现功能也导致大部分OpenID 's problems because the way it is implemented is by using HTTP URIs as identifiers which most web users just don' t获取 . OpenID的其他功能是支持使用DH交换进行临时客户端注册，支持优化最终用户体验的即时模式，以及在不向提供商进行另一次往返的情况下验证断言的方法 .
为了处理身份验证，你'll likely want to look into OpenID Connect, which is essentially another layer on top of the foundation set by OAuth 2.0. Here'是一个引用（在我看来）有关OpenID Connect（来自https://oauth.net/articles/authentication/）的最突出点的引用：
17 回答
OpenID是关于身份验证（即证明你是谁），OAuth是关于授权（即授予对功能/数据/等的访问权限而不必处理原始身份验证） .
OAuth可以在外部合作伙伴站点中使用，以允许访问受保护的数据，而无需重新验证用户 .
博客文章“OpenID versus OAuth from the user’s perspective " has a simple comparison of the two from the user's perspective and " OAuth-OpenID: You’re Barking Up the Wrong Tree if you Think They’re the Same Thing”提供了有关它的更多信息 .
有三种方法可以比较OAuth和OpenID：
1. Purposes
OpenID was created for federated authentication, that is, letting a third-party authenticate your users for you, by using accounts they already have . 联邦这一术语在这里至关重要，因为OpenID的重点在于可以使用任何提供者（白名单除外） . 您无需预先选择或与提供商协商，以允许用户使用他们拥有的任何其他帐户 .
OAuth was created to remove the need for users to share their passwords with third-party applications . 它实际上是一种解决OpenID问题的方法：如果您在自己的网站上支持OpenID，则可以在您的网站上输入密码 .
问题在于OpenID用于身份验证和OAuth的分离用于授权是两个协议都可以完成许多相同的事情 . 它们各自提供了不同实现所需的不同功能集，但实际上它们是可以互换的 . 两个协议的核心是断言验证方法（OpenID仅限于'这就是我自己'的断言，而OAuth提供了一个'访问令牌'，可以通过API交换任何支持的断言） .
2. Features
这两种协议都为站点提供了一种方法，可以将用户重定向到其他位置，并返回可验证的断言 . OpenID provides an identity assertion while OAuth is more generic in the form of an access token which can then be used to "ask the OAuth provider questions" . 但是，它们各自支持不同的功能：
OpenID - OpenID最重要的特性是它的发现过程 . OpenID不需要对要提前使用的每个提供程序进行硬编码 . 使用发现，用户可以选择要进行身份验证的任何第三方提供商 . 此发现功能也导致大部分OpenID 's problems because the way it is implemented is by using HTTP URIs as identifiers which most web users just don' t获取 . OpenID的其他功能是支持使用DH交换进行临时客户端注册，支持优化最终用户体验的即时模式，以及在不向提供商进行另一次往返的情况下验证断言的方法 .
OAuth - OAuth最重要的功能是访问令牌，它提供了一种持久的方法来发出额外的请求 . 与OpenID不同，OAuth不以身份验证结束，而是提供访问令牌以访问由同一第三方服务提供的其他资源 . 但是，由于OAuth不支持发现，因此需要预先选择并对您决定使用的提供程序进行硬编码 . 访问您网站的用户不能使用任何标识符，只能使用您预先选择的标识符 . 此外，OAuth没有身份概念，因此将其用于登录意味着要么添加自定义参数（由Twitter完成），要么进行另一个API调用以获取当前"logged in"用户 .
3. Technical Implementations
这两个协议在使用重定向获取用户授权时共享一个共同的体系结构 . 在OAuth中，用户授权访问其受保护资源和OpenID中的身份 . 但这就是他们共享的一切 .
每种协议都有不同的计算签名的方式，用于验证请求或响应的真实性，每种协议都有不同的注册要求 .
OpenID（主要）用于识别/认证，因此
stackoverflow.com知道我拥有chris.boyle.name（或任何地方），因此我可能是昨天拥有chris.boyle.name且获得一些声望点的同一个人 .OAuth旨在授权代表您执行操作，以便
stackoverflow.com（或任何地方）可以在不知道您的Twitter密码的情况下自动代表您发送Tweet权限 .许多人仍然访问这个，所以这里有一个非常简单的图解释它
Courtesy Wikipedia
OAuth
仅用于委派 authorization - 表示您授权第三方服务访问以使用个人数据，而不提供密码 . 此外，OAuth "sessions"通常比用户会话更长寿 . 这意味着OAuth旨在允许授权
即Flickr使用OAuth允许第三方服务代表他们发布和编辑人物图片，而不必提供他们的闪烁用户名和密码 .
OpenID
用于 authenticate 单点登录身份 . 所有OpenID应该允许OpenID提供商证明你说你是 . 然而，许多站点使用身份验证来提供授权（但是两者可以分开）
即一个人在机场出示他们的护照，以证明（或证明）他们正在使用的机票名称的人是他们 .
如果您的用户可能只想使用Facebook或Twitter登录，请使用OAuth . 如果您的用户是，请使用OpenID运行自己的OpenID提供商的领带，因为他们“不希望任何其他人拥有自己的身份” .
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/
The explanation of the difference between OpenID, OAuth, OpenID Connect:
(source)
(source)
(source)
Google's OAuth 2.0
(source)
问题的延伸比答案更多，但也可能为上面的重大技术答案添加一些观点 . 我是一个经验丰富的程序员，涉及多个领域，但总体上是为网络编程的菜鸟 . 现在尝试使用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 ...） . 由于这个网站正在这样做，这里的某些人可能对这个主题有一些非常好的见解 . :-)
对不起，这是一个很长的问题，而不是一个问题 - 但卡尔的评论使它看起来似乎是最适合在OAuth和OpenID线程中发布的地方 . 如果有一个更好的地方，我没有找到，我提前道歉，我尝试过 .
OpenID Connect （OIDC）是一种认证协议，基于 OAuth 2.0 （即 O pen Auth orization）系列规范 . 它使用简单的JSON Web令牌（JWT），您可以使用符合 OAuth 2.0 规范的流程获取它 . OAuth 与 OpenID Connect （OIDC）直接相关，因为 OIDC 是在 OAuth 2.0 之上构建的身份验证层
OAuth 2.0 是关于资源访问和共享，即授权， OIDC 是关于用户身份验证的 . 它的目的是为您提供多个站点的登录 . 每次您需要使用 OIDC 登录网站时，您将被重定向到您登录的OpenID站点，然后返回到该网站 .
OpenID Connect（OIDC）是OAuth 2.0（授权框架）之上的身份验证层 . 该标准由OpenID基金会控制：
For example ，如果您选择使用自己的Google帐户登录Auth0，则使用 OIDC . 成功通过Google进行身份验证并授权Auth0访问您的信息后，Google会向Auth0发回有关用户和执行身份验证的信息 . 此信息在JSON Web令牌（JWT）中返回 . 您将收到一个访问令牌，如果需要，还会收到一个ID令牌 . Types of Token：Source: OpenID Connect
Analogy ：
组织使用 ID card 进行识别，它包含芯片，它存储有关员工的详细信息以及 Authorization 即校园/门/ ODC访问 . ID Card 充当 OIDC 和 Chip 充当 OAuth . more examples
OpenID 证明你是谁 .
OAuth 授予访问授权方提供的功能的权限 .
我目前正在研究OAuth 2.0和OpenID连接规范 . 所以这是我的理解：早些时候他们是：
OpenID是专有的谷歌的实施允许第三方应用程序，如报纸网站，您可以使用谷歌登录和评论文章等其他用例 . 基本上，没有密码共享到报纸网站 . 让我在这里提出一个定义，这种方法在企业方法中称为联合 . 在联合中，您有一个服务器，您可以在其中进行身份验证和授权（称为IDP，身份提供程序），通常是用户凭据的管理员 . 您拥有业务的客户端应用程序称为SP或服务提供商 . 如果我们回到同一个报纸网站的例子，那么报纸网站就是SP，Google就是IDP . 在企业中，此问题早先使用SAML解决 . 那个时候用来统治软件行业的XML . 所以从Web服务到配置，过去所有的东西都转到XML，所以我们有SAML，一个完整的联邦协议
OAuth：OAuth看到它作为一种标准出现在所有这些专有方法中，因此我们将OAuth 1.o作为标准，但仅针对授权 . 没有多少人注意到它，但它开始有所收获 . 然后我们在2012年获得了OAuth 2.0.当全球正朝着 Cloud 计算和计算设备转向移动和其他此类设备时，CTO，架构师真正开始关注 . OAuth被视为解决主要问题，软件客户可能会向一家公司提供IDP服务，并且拥有来自不同供应商的许多服务，例如salesforce，SAP等 . 因此，这里的集成看起来真的像联邦方案有点大问题，使用SAML是昂贵的让我们来探索OAuth 2.o.哦，错过了一个重要的观点，即在此期间，Google感觉到OAuth实际上没有解决身份验证问题，IDP将如何将用户数据提供给SP（实际上在SAML中实际上很好地解决）以及其他松散的目标，例如：
一个 . OAuth 2.o没有明确说明客户注册将如何发生b . 它没有提到任何关于SP（资源服务器）和客户端应用程序之间的交互（比如提供数据的Analytics Server是资源服务器和显示数据是客户端的应用程序）
从技术上讲，这里已经有了很好的答案，我想到给出简要的进化观点
OpenId使用OAuth来处理身份验证 .
通过类比，它就像.NET依赖于Windows API . 您可以直接调用Windows API，但它如此广泛，复杂且方法论据如此庞大，您可能很容易犯错误/错误/安全问题 .
与OpenId / OAuth相同 . OpenId依靠OAuth来管理身份验证，但定义了特定的令牌（Id_token），数字签名和特定流 .
我想谈谈这个问题的一个特定方面，如本评论中所述：
是的......没有 . 答案很微妙，所以请耐心等待 .
当OAuth流将您重定向到目标服务（即OAuth提供程序）时，您可能需要在将令牌传回客户端应用程序/服务之前对该服务进行身份验证 . 然后，生成的令牌允许客户端应用程序代表给定用户发出请求 .
注意最后一句话的一般性：具体来说，我写了"on behalf of a given user"， not “代表 you ". It's a common error to assume that "具有与给定用户拥有的资源进行交互的能力" implies "你和目标资源的所有者是一个相同” .
Don't make this mistake.
虽然您确实使用OAuth提供程序进行身份验证（例如，通过用户名和密码，或者SSL客户端证书或其他方式），但客户端得到的回报不一定被视为身份证明 . 一个示例是一个流程，其中访问另一个用户的资源被委托给您（以及代理，OAuth客户端） . 授权并不意味着身份验证 .
为了处理身份验证，你'll likely want to look into OpenID Connect, which is essentially another layer on top of the foundation set by OAuth 2.0. Here'是一个引用（在我看来）有关OpenID Connect（来自https://oauth.net/articles/authentication/）的最突出点的引用：
然后，该文档继续描述（除其他外）令牌ID和UserInfo endpoints . 前者提供了一组声明（当你发出令牌时，你是谁，也可能是签名，通过发布的公钥验证令牌的真实性，而不必询问上游服务），后者提供了例如，以标准化的方式询问用户的姓/名，电子邮件和类似的信息（与人们在OpenID Connect标准化事物之前使用的OAuth的临时扩展相反） .
两种协议都是出于不同原因而创建的创建OAuth是为了授权第三方访问资源 . 创建OpenID是为了执行分散式身份验证 . 这website陈述如下：
OAuth是一种协议，旨在验证最终用户的身份并向第三方授予权限 . 此验证会产生令牌 . 第三方可以使用此令牌代表用户访问资源 . 代币有一个范围 . 范围用于验证资源是否可供用户访问
OpenID是用于分散式身份验证的协议 . 身份验证是关于身份; Build 用户实际上是他声称的那个人 . 权力下放意味着该服务不知道存在任何需要保护的资源或应用程序 . 这是OAuth和OpenID之间的关键区别 .
OAuth在授权之上构建身份验证：用户将对其身份的访问权委托给应用程序，然后该应用程序成为身份API的使用者，从而找出谁首先授权客户端http://oauth.net/articles/authentication/