根据您的解释，OAuth 2.0 似乎更适合您的需求。OpenID Connect 旨在为 OAuth 2.0 添加安全身份验证。Google、Facebook、Yahoo 等大型提供商开始使用 OAuth 2.0 作为一种通过“登录方式”服务对用户进行身份验证的方式，以便用户可以使用他们的凭据对各种第三方服务进行身份验证。由于协议中的缺陷，标准 OAuth 2.0 无法安全地满足此要求。OpenID Connect 解决了这些缺陷并允许提供商安全地使用 OAuth 2.0 作为身份验证框架。OAuth 2.0 最初是作为授权框架开发的，它允许用户授予第三方服务访问其存储在提供程序上的数据的权限。您描述的场景似乎正是 OAuth 2.0 的开发目的。

如果用户将拥有自己的第三方服务凭据，并且不使用您的提供商凭据登录服务，则您不需要 OpenID Connect。

这是我发现的最有用的资源。这是 OpenID Connect 的一位设计者的博客文章，阐述了 Facebook 对 OAuth 2.0 的不同用途。

首先，您可能知道，OpenID Connect 只是构建在 OAuth2 之上的身份验证层。因此，无论您选择哪个，您都需要实施 OAuth2（作为共同点）。

OAuth2 本身是一种授权机制（即，允许您检查令牌是否有效并授予一组特定的范围）。它不提供开箱即用的身份验证（您不能立即告诉用户“谁”）。

但是在许多情况下，您可能希望同时拥有授权和身份验证。在这种情况下，您需要在 OAuth2 之上的一个层来提供它。最常见的做法是让资源服务器公开某种“我是谁？” 返回与访问令牌关联的用户身份的端点。

OpenID Connect 做到了这一点，并提供了一种标准方法来获取用户身份（即UserInfo端点返回的对象）并将其表示为一组声明。

它还使客户端应用程序能够接收用户信息以及访问令牌（即令牌端点返回的id_token或作为签名的 JWT 令牌与授权代码一起包含的id_token，具体取决于您的流程），从而保存 HTTP 请求。

OpenID Connect 还提供了一堆 IMO 不太感兴趣的其他东西（动态注册等）。

因此，要回答您关于 OAuth2 与 OpenID Connect 的问题：如果您需要对 API 进行身份验证，则必须在 OAuth2 之上实现它。您可以做一些自定义的事情，也可以实施 OpenID Connect。如果您想实现整个规范， OpenID Connect非常复杂，但如果您只想实现 MVP 来验证用户身份（实现用户信息端点并使用标准表示，可能会发出 id_tokens），则相对容易。

有关更多信息，请参阅OpenID Connect 规范。