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 滥用到身份验证协议中。在酒店的类比中：如果我遇到一个自称的员工并且那个人向我展示他有一把打开我房间的钥匙，那么我想 这是一个真正的雇员，因为如果他没有给他一把打开我房间的钥匙，钥匙主人就不会给他一把钥匙。

简单的术语

1. OpenID 是关于验证一个人的身份（身份验证）。
2. OAuth 是关于访问一个人的东西（授权）。
3. OpenID Connect两者兼而有之。

这三个都允许一个人将他们的用户名/密码（或其他凭据）提供给受信任的机构，而不是提供给不太受信任的应用程序。

更多细节

要了解某事，请查看其历史。

OpenID 和 OAuth 在平行轨道上发展，并于 2014 年合并到 OpenID Connect。纵观其历史，OpenID 和 OAuth 让应用程序使用受信任的权限来处理私人用户凭据。OpenID 让权威机构验证用户的身份，而 OAuth 让权威机构授予对用户资料的有限访问权限。

OpenID 1.0 (2006) 允许应用程序向权威机构询问最终用户拥有身份（URL）的证据。

• 最终用户到应用程序：我是 Steve A. Smith。
• 应用到权威：这是史蒂夫·A·史密斯吗？
• 最终用户和权威会说话。
• 应用权限：是的，那是 Steve A. Smith。

OpenID 2.0 (2007) 做了同样的事情，但添加了第二种身份格式 (XRI) 并为最终用户指定身份和权限的方式增加了灵活性。

OpenID Attribute Exchange 1.0 (2007) 扩展了 OpenID 2.0，除了验证最终用户的身份外，还允许应用获取和存储具有权限的最终用户配置文件信息。

• 最终用户到应用程序：我是 Steve A. Smith。
• 应用到权威：这是史蒂夫·A·史密斯吗？哦，如果是的话，还给我他的电子邮件地址和电话号码。
• 最终用户和权威会说话。
• 应用权限：是的，那是 Steve A. Smith。他的电子邮件是 steve@domain.com，电话号码是 123-456-7890。

OAuth 1.0 (2010) 允许最终用户授予应用程序对授权拥有的第三方服务器上资源的有限访问权限。

• 应用到最终用户：我们想在其他服务器上访问您的图片。
• 最终用户和权威会说话。
• 应用权限：这是一个访问令牌。
• 应用到第三方服务器：这是证明我可以为最终用户访问图片的访问令牌。

OAuth 2.0 (2012) 与 OAuth 1.0 做同样的事情，但使用了全新的协议。

OpenID Connect (2014) 在一个协议中结合了 OpenID 2.0、OpenID Attribute Exchange 1.0 和 OAuth 2.0 的功能。它允许应用程序使用权限...

1. 验证最终用户的身份，
2. 获取最终用户的个人资料信息，以及
3. 获得对最终用户资料的有限访问。

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

礼貌维基百科

我们已经有一个图表和很多好的数据，所以这里有一个例子，以防万一。

假设我想向 StackOverflow 发表评论。StackOverflow 仅在用户拥有 50 名声望时才允许评论。

StackOverflow 必须授权此请求（例如，仅当用户具有 >= 50 代表时才允许它）。StackOverflow 不会使用 OAuth 来执行此操作，因为 StackOverflow 拥有受保护的资源。如果 StackOverflow 试图代表用户向 Facebook 发表评论，那么它将使用 OAuth。相反，StackOverflow 将使用本地授权（例如if (user.reputation < 50) throw InsufficientReputationError();）

为了做到这一点，StackOverflow 必须首先知道谁在发出请求。换句话说，为了授权请求，它必须首先验证请求。

StackOverflow 首先检查会话和 HTTP 标头以查看是否可以快速验证用户身份（例如，这不是他们的第一个请求）但失败了。

让我们假设 StackOverflow 决定使用 OpenID Connect。这意味着 StackOverflow 信任身份提供者。这是 StackOverflow 信任的服务，它可以告诉 StackOverflow 当前用户是谁。在此示例中，我们将假设是 Google。

StackOverflow 现在询问 Google 当前用户是谁。但是，Google 必须首先确保允许 StackOverflow 知道当前用户是谁。换句话说，谷歌必须授权StackOverflow。由于 Google 是受保护资源的所有者，而 StackOverflow 是访问它的人，我们可以在此处使用 OAuth。事实上，OpenID Connect 强制要求这样做。

这意味着 StackOverflow 必须通过Google 信任的授权服务器进行身份验证（实际上，这也可能是 Google，但不一定是这种情况）并获得访问令牌。它将访问令牌带到 Google 并询问用户的身份。然后，Google 返回用户的身份（在途中签署身份），而 StackOverflow 则在知道用户身份后授权该请求。

如果您错过了它，每个都有多个身份验证和授权步骤。

• StackOverflow 尝试使用会话 cookie 对请求进行身份验证，但失败了。
• StackOverflow 然后使用 OpenID Connect 对请求进行身份验证
• Google使用 OAuth授权SO 的身份请求
• 授权服务器对StackOverflow 进行了身份验证（可能使用客户端 ID 和客户端密码）。
• 此外，作为 OAuth 工作流程的一部分，授权服务器可能通过询问用户的用户名和密码来验证请求。
• 此外，用户自己可能已经通过响应授权屏幕授权了SO 的身份请求（例如，“你想允许 StackOverflow 访问你的电子邮件吗？”）
• StackOverflow通过确保用户的信誉 >50 来授权请求。

什么是 OpenID（没有连接）？

这是一个较早的协议，它允许身份提供者（如 Google）将用户信息传递给服务（如 StackOverflow）。但是，它使用另一种方法（不是 OAuth）让 Google 授权 StackOverflow 可以访问用户的身份。OpenID 有一些安全漏洞（我相信已经解决），但在我看来，真正的杀手只是 OAuth 有更好的支持这一事实，因此与学习 OpenID 的自定义协议相比，工作量往往更少。

直到今天，每个人都在放弃它。不要使用它。使用 OpenID 连接。

“滥用”OAuth

在我上面描述的场景中，OAuth 的使用完全符合授权的预期。但是，还有另一种工作流程经常会使人们感到困惑。这是因为在许多情况下（大多数？），提供用户身份的服务器和 OAuth 授权服务器是同一台服务器。

在这种情况下，首先向授权服务器发出 HTTP 请求以获取访问令牌，然后再次向同一服务器发出 HTTP 请求以获取身份令牌，这似乎有点过分。因此，为 OAuth 规范创建了一个扩展，以允许授权服务器将用户身份信息与访问令牌捆绑在一起。

这允许身份验证完全在浏览器中进行（例如不需要涉及 StackOverflow 的服务器）。但是，这种身份验证不太有用，而且（我认为？）不太常用。