我现在已经阅读了许多不同的文章，但我仍然不清楚 OpenID Connect 在 OAuth 2.0 之上提供的主要值(value)。
我的理解:
通过 OAuth 2.0 流程接收访问 token 时，客户端确实知道用户已通过授权服务器的身份验证。似乎 OpenID Connect 只是添加了一个带有用户信息的 ID token - 但该信息可能是访问 token 的一部分，也可以通过 protected 资源(如单独的 userDetails 资源)获得。这似乎不能证明 OpenID Connect 的创建是合理的，所以我确定我遗漏了一些东西......
谢谢你的帮助!
添加更多对于评论来说太长的细节。非常感谢您到目前为止的帮助。
感谢您的回复，我想我越来越近了。所以我回顾了这篇文章:http://oauth.net/articles/authentication/ .它说“OAuth 对用户一无所知”。但是，您信任相同的服务在颁发访问 token 之前对最终用户进行身份验证。在“常见陷阱”部分，文章讨论了为什么不能使用访问 token 进行身份验证。据我了解，我有以下问题:
访问 token 作为身份验证证明
访问 token 是之前某个时间点的身份验证证明。如果客户端确实想在获得访问 token 后的某个时间点对用户进行身份验证，为什么不重复现有的 Oauth 流程，当前最终用户尝试访问客户端呢？
访问 protected 资源作为证据
与上面相同 - 如果客户端在任何时候都需要身份验证，请重复 Oauth 流程。
访问 token 注入(inject)
不清楚 OpenID 如何帮助这一点
缺乏观众限制
为什么将有效的 ID token 与访问 token 一起交给天真的客户更难？这与服务器端流程完全相关吗？同样，如果需要，可以重复 OAuth 流程。
注入(inject)无效用户信息
这似乎需要签名，而不是单独的 token 。如果 OAuth 流程通过 HTTPS 进行，是否会为身份提供者添加任何安全措施以两次签署用户详细信息？
每个潜在身份提供者的不同协议(protocol)
这看起来很公平，但如果唯一的目的是标准化用于用户信息的 token ，这似乎仍然很奇怪。
最佳答案
OAuth 访问 token 对客户端是不透明的，并且可以由任何人提供，这意味着它不一定由登录用户交给客户端。攻击者可以向客户端提供一个访问 token ，该 token 是在其自己的(不一定是恶意的)服务中从其他用户那里获得的。来自 OpenID Connect 的 ID token 可确保用户最近在 OP 上登录，并提供客户端可以验证的有关该用户的信息。此外，ID token 专门针对您的客户。
http://oauth.net/articles/authentication/ 中很好地描述了这些差异。
关于oauth - OpenID Connect 为 OAuth 2.0 添加了什么(为什么 OAuth 2.0 不足以进行身份验证？)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/33934920/