我现在已经阅读了很多不同的文章，但我仍然不清楚OpenID Connect在OAuth 2.0之上提供的主要 Value .
我的理解：
当通过OAuth 2.0流接收访问令牌时，客户端确实知道授权服务器已对用户进行了身份验证 . 似乎OpenID Connect只是添加了带有用户信息的ID令牌 - 但该信息可以是访问令牌的一部分，也可以通过受保护资源（如单独的userDetails资源）获得 . 那不确定我错过了什么......
谢谢你的帮助！
添加更多详细信息，以便评论 . 非常感谢你的帮助 .
由于你的回答，我想我越来越近了 . 所以我回顾了这篇文章：http://oauth.net/articles/authentication/ . 它说"OAuth says absolutely nothing about the user" . 但是，在发出访问令牌之前，您信任相同的服务来验证最终用户 . 在"common pitfalls section"中，本文讨论了为什么不能使用访问令牌进行身份验证 . 根据我的理解，我有以下问题：
Access token as proof of authentication 访问令牌是某个先前点的身份验证证明 . 如果客户端确实想在获取访问令牌后的某个时刻对用户进行身份验证，为什么不重复现有的Oauth流，当前最终用户尝试访问客户端？
Access of a protected resource as proof 与上述相同 - 如果客户端需要在任何时候进行身份验证，请重复Oauth流 .
Injection of access tokens 不清楚OpenID如何帮助这一点
Lack of audience restriction 为什么向天真的客户端提供有效的ID令牌和访问令牌更难？这对服务器端流程是否相关？同样，如果需要，可以重复OAuth流程 .
Injection of invalid user information 这似乎需要签名，而不是单独的令牌 . 如果OAuth流程通过HTTPS进行，是否为身份提供商添加了两次安全性以签署用户详细信息？
Different protocols for every potential identity provider 这看起来很公平，但如果唯一的目的是用于标识用户信息的令牌，那似乎仍然很奇怪 .
3 回答
OAuth访问令牌对客户端是不透明的，并且可能由任何人提供，这意味着它不一定由登录用户传递给客户端 . 攻击者可以向客户端提供访问令牌，该令牌来自其自身（不一定是恶意）服务中的其他用户 . 来自OpenID Connect的ID令牌确保用户最近在OP登录，并提供有关该客户可以验证的用户的信息 . 此外，ID令牌专门针对您的客户 .
在http://oauth.net/articles/authentication/中描述的差异相当不错
身份令牌可以由身份验证服务器签名 . 客户端应用程序 can verify the signature 确认最终用户已通过身份验证服务器进行身份验证 . 访问令牌保护的资源调用不提供这样的机制 .
此外，OpenID Connect还引入了与身份验证相关的其他机制，例如：
身份验证上下文类参考
最大认证年龄
在
claims请求参数中声明了sub满足政府更高层次的安全要求 .
阅读OpenID Connect Core 1.0和其他相关规范 . 此外，您可能会发现“Authorization interaction”有助于总结OpenID Connect添加哪些内容来控制最终用户身份验证 .
OAuth 2.0旨在授予第三方对资源的有限访问权限 . The RFC以 . 开头
OpenID Connect是关于 Build 最终用户的身份 . OpenID Connect Core spec以 . 开头
在OAuth 2.0中，当资源服务器收到包含访问令牌的请求时，资源服务器知道资源所有者已授予第三方对资源的访问权限 . 访问令牌代表此批准，但它不识别呈现它的第三方 .
如果一家公司认为像Salesforce或Google这样的人比管理用户帐户，密码，数字证书等更好，那么该公司可以使用OpenID Connect将该责任基本上“外包”给OpenID Connect Provider . 当公司在OpenID Connect流的上下文中收到id令牌时，它知道提供者已经对最终用户进行了身份验证并 Build 了用户的身份 .
OpenID Connect重新利用了OAuth 2.0流程，以便 Build 最终用户的身份 .