我看到一些帖子坚持认为 OAuth 与 OpenID 完全不同，因为 OpenID 是关于对用户进行身份验证，而 OAuth 是关于将某些服务的访问权限授予第三方。
但是，我知道很多人无论如何都使用 OAuth 作为身份验证，如此处所示，维基百科称其为“伪身份验证”，但它看起来是一种有效的方式。与使用 OpenID 相比有什么缺点吗？如果 OAuth 可以进行身份验证，这是否意味着 OAuth 可以做 OpenID 所做的一切，但 OpenID 不能做 OAuth 所做的事情（比如访问服务）。那么为什么人们会使用 OpenID 而不是 OAuth 呢？
注意：我是初学者，所以如果我错过了一些基本的东西，请原谅并指出。
OAuth 设计用于应用程序 X 需要访问由应用程序 Y 控制并属于用户 A 的资源（例如，“我的照片”或“我的电子邮件地址”或“我的日历”）的情况——用户 A 可能希望授予对这些资源的访问权限应用程序 Y 上的资源，但他不想向应用程序 X 提供他的实际用户名/密码凭据。因此，访问令牌用作应用程序 Y 上资源的替代凭证。访问令牌可以独立于用户名/密码凭证而被撤销，并且理想情况下，其范围很窄，只允许访问特定资源。
使用 OAuth 2 进行身份验证会以可能存在风险的方式重载该模型。查看上面的示例，并想象它被用于身份验证。如果应用程序 X 使用该访问令牌进行身份验证，那么它会获取一个授予对应用程序 Y 上资源的访问权限的令牌，并使用它来授予对自己资源的访问权限。也许这有点让人费解，因为重要的是我们知道通过 OAuth 2 授予访问令牌的行为意味着用户已成功通过身份验证。问题是访问令牌没有说明最终用户验证了哪个应用程序. 那么，如果应用程序 Z 也有用户 A 在应用程序 Y 上的资源的访问令牌，会发生什么情况呢？如果应用程序 Z 可以让应用程序 X 使用此访问令牌，则它可以访问用户 A在应用程序 X 上的资源。那很糟。用户 A 可能信任应用程序 Z 访问他在应用程序 Y 上的资源，但用户 A 肯定从未同意应用程序 Z 访问他在应用程序 X 上的资源。
OpenID 和 OpenID Connect 专为身份验证而设计。OpenID Connect 构建在 OAuth 2 之上，因此它可以利用现有的交互和流程，但它添加了一个称为 ID 令牌的实体，它是一个包含一组关于身份验证事件的声明的对象。这些声明包括执行身份验证的用户的标识符、处理身份验证的服务器的标识符以及身份验证的受众的标识符。这为应用程序提供了验证用户是否代表其进行身份验证所需的信息。
每当我比较两者时，我认为它们是主动和被动识别/身份验证模型之间的区别，openID 是被动的，OAuth 是主动的。
被动告诉请求应用程序做什么，例如从身份提供者重定向到应用程序的 Web 浏览器，并且浏览器是一个基本的哑客户端，因为它只做它被告知要做的事情。Active 要求请求应用程序知道当它收到数据时要做什么，并且它对数据做任何它想做的事情，例如令牌。
活动模型允许应用程序使用用户令牌向 API 发出直接请求，因为它已将令牌存储在本地。被动模型要求用户通过重定向到提供者进行身份验证，并使用临时令牌返回应用程序。（在技术上不是临时的，但它符合解释）
根据您尝试对应用程序执行的操作，任何一种模型都可以工作。
关键的区别在于，在 OpenID 身份验证用例中，来自身份提供者的响应是身份断言；而在 OAuth 授权用例中，身份提供者也是 API 提供者，来自身份提供者的响应是一个访问令牌，可以代表用户授予应用程序对身份提供者的某些 API 的持续访问权限。访问令牌充当一种“代客密钥”，应用程序可以将其包含在其对身份提供者的请求中，这证明它具有用户访问这些 API 的权限。
由于身份提供者通常（但不总是）将用户身份验证作为授予 OAuth 访问令牌过程的一部分，因此很容易将成功的 OAuth 访问令牌请求视为身份验证方法本身。但是，由于 OAuth 在设计时并未考虑到此用例，因此做出此假设可能会导致重大安全漏洞
