OpenID Connect为OAuth 2.0添加了什么（为什么OAuth 2.0不足以进行身份​​验证？）

Question

我现在已经阅读了很多不同的文章，但我仍然不清楚OpenID Connect在OAuth 2.0上提供的主要价值。

我的理解：
当通过OAuth 2.0流接收访问令牌时，客户端确实知道授权服务器已对用户进行了身份验证。似乎OpenID Connect只是添加了带有用户信息的ID令牌 - 但该信息可以是访问令牌的一部分，也可以通过受保护资源（如单独的userDetails资源）获得。这似乎不足以证明OpenID Connect的创建，所以我确信我错过了一些东西......

感谢您的帮助！

添加评论太长的详细信息。非常感谢你们的帮助。

由于你的回答，我认为我越来越近了。所以我回顾了这篇文章：http://oauth.net/articles/authentication/。它说“OAuth对用户一无所知”。但是，在发出访问令牌之前，您信任相同的服务来验证最终用户。在“常见陷阱部分”中，本文讨论了为什么不能使用访问令牌进行身份验证。根据我的理解，我有以下问题：

访问令牌作为身份验证证明 访问令牌是某个先前点的身份验证证明。如果客户端确实想要在获取访问令牌后的某个时刻对用户进行身份验证，为什么不重复现有的Oauth流，当前最终用户尝试访问客户端？

访问受保护资源作为证据 与上述相同 - 如果客户端需要在任何时候进行身份验证，请重复Oauth流程。

注入访问令牌 不清楚OpenID如何帮助这个

缺乏受众限制 为什么向天真的客户端提供有效的ID令牌和访问令牌更难？这与服务器端流程有关吗？同样，如果需要，可以重复OAuth流程。

注入无效的用户信息 这似乎需要签名，而不是单独的令牌。如果OAuth流程通过HTTPS进行，是否为身份提供商添加任何安全性以对用户详细信息签署两次？

每个潜在身份提供商的不同协议 这似乎是公平的，但如果唯一的目的是用于用户信息的令牌的标准化，它似乎仍然很奇怪。

Answer 1

OAuth访问令牌对客户端是不透明的，并且可能由任何人提供，这意味着它不一定由登录用户传递给客户端。攻击者可以向客户端提供访问令牌，该令牌来自其自身（不一定是恶意）服务中的其他用户。来自OpenID Connect的ID令牌可确保用户最近在OP上登录，并提供有关该客户可以验证的用户的信息。此外，ID令牌专门针对您的客户。

在http://oauth.net/articles/authentication/

中很好地描述了这些差异

Answer 2

身份验证服务器可以签署ID令牌。客户端应用程序可以验证签名，以确认最终用户已经过身份验证服务器的身份验证。访问令牌+受保护的资源调用不提供这样的机制。

此外，OpenID Connect还引入了与身份验证相关的其他机制，例如：

1. 身份验证上下文类参考
2. 最长认证年龄
3. sub在claims请求参数
中声明

满足政府更高层次的安全要求。

阅读OpenID Connect Core 1.0和其他相关规范。此外，您可能会发现“Authorization interaction”有助于总结OpenID Connect添加哪些内容来控制最终用户身份验证。

Answer 3

OAuth 2.0旨在授予第三方对资源的有限访问权限。 The RFC以

开头

  

OAuth 2.0授权框架支持第三方   应用程序以获得对HTTP服务的有限访问...

OpenID Connect是关于建立最终用户的身份。 OpenID Connect Core spec以

开头

  

OpenID Connect 1.0是OAuth 2.0之上的简单身份层   协议。它使客户端能够验证最终用户的身份   基于授权服务器执行的身份验证...

在OAuth 2.0中，当资源服务器收到包含访问令牌的请求时，资源服务器知道资源所有者已授予第三方对资源的访问权限。访问令牌代表此批准，但它不识别出现它的第三方。

如果一家公司认为像Salesforce或Google这样的人比管理用户帐户，密码，数字证书等更好，公司可以使用OpenID Connect将该责任基本上“外包”给OpenID Connect Provider。当公司在OpenID Connect流的上下文中收到id令牌时，它知道提供者已经对最终用户进行了身份验证并建立了用户的身份。

OpenID Connect重新利用OAuth 2.0流程，以便建立最终用户的身份。