我刚刚开始使用OAuth 2.0作为对我的用户进行身份验证的一种方式。效果很好——我只是使用每个提供商的身份/配置文件 API 来获取用户的经过验证的电子邮件地址。
现在我读到了OpenID Connect并且有点困惑。
OpenID Connect 和通过 OAuth2 使用身份 API 有什么区别？仅仅是因为我有一个标准的配置文件 API，所以我不必担心我得到的"email"是 JSON 还是"emails"JSON？
还是有更多的东西，这使得 OpenID Connect 方法比我的第一种方法更安全？
OAuth 只提供并且应该只提供使用访问令牌的授权。OpenID connect 基于 OAuth 2 构建，以提供用户身份验证信息。但是，它不会为您提供比 OAuth 更健壮的实现（因为它使用 OAuth 并添加了一些与 OpenID 提供程序的额外交互）。
OpenID Connect 1.0 是 OAuth 2.0 [RFC6749] 协议之上的一个简单身份层。它使客户端能够根据授权服务器执行的身份验证验证最终用户的身份，并以可互操作和类似 REST 的方式获取有关最终用户的基本配置文件信息。 OpenID Connect Core 1.0 - 草案 17
OpenID connect 为您提供了一种获取用户身份的“标准”方式。如果您使用 OAuth 和 API，您应该调整您对每个资源的请求，这些资源可能并不总是提供相同的信息，或者可能会随着时间而改变。从概念上讲，您使用 OAuth 是为了被允许使用 API，而不是对用户进行身份验证。
作为背景，OAuth 2.0 授权框架 [RFC6749] 和 OAuth 2.0 承载令牌使用 [RFC6750] 规范为第三方应用程序获取和使用对 HTTP 资源的有限访问权提供了一个通用框架。它们定义了获取和使用访问令牌来访问资源的机制，但没有定义提供身份信息的标准方法。值得注意的是，如果不分析 OAuth 2.0，它就无法提供有关最终用户身份验证的信息。OpenID Connect Core 1.0 - 草案 17
请注意，OpenID connect 提供了id_token一些关于用户的信息。但是，如果您想要整套信息，您仍然需要access_token请求 OpenID 提供程序来获取用户信息（我第一次看到它时让我很困惑）。这表明从 API 或 OpenID 提供者请求用户信息使用几乎相同的方法。见5.3.1. userinfo request草稿。
OAuth 是一种授权协议，提供了一种授权访问受保护资源的方法。授权过程的一个副产品是对用户进行身份验证。
从技术上讲，OAuth 不必向您提供有关用户的任何信息。它提供的是用户已授权应用程序访问某些数据的验证。这取决于授权授予的范围。
OpenID Connect 为应用程序提供了一种方法来检索有关经过身份验证的用户的信息。最重要的是，它提供了信息有效的保证级别（就授权服务器而言）。这可以用来促进身份联合。
过去，联合是通过 OAuth 通过授予允许访问用户身份信息的范围来实现的。OpenID Connect 使该范围标准化。
OpenID Connect 是 OAuth2 的配置文件......定义了一种体系结构，使人们能够授权身份提供者向客户端（网站/移动应用程序）发布某些用户声明。
OAuth2 提供资源所有者密码凭证授予，IAM 专家将其正确地诬蔑为“魔鬼”。
OpenID Connect API 的常见模式是三个步骤：
1) 获取代码
2) 获取令牌，如access_token、refresh_token和id_token
3) 获取包含用户名、电子邮件等声明的用户信息。
id_token 的架构，它是一个 JWT , 在 OpenID Connect 范围内定义，许多其他细节也是如此。
使用 OpenID Connect 的另一个原因是移动软件（至少 IOS 和 Android）的集中身份验证有一个安全的解决方案。Google 定义的当前最佳实践是使用新的安全功能来阻止移动应用程序在 Web 视图中查看 cookie 或凭据。Google 发布了 AppAuth IOS 和 Android 库，因为他们真的不希望您泄露 Google 凭据！在撰写本文时，有几个 OpenID 提供程序（又名 IDP 的...）支持 Google OpenID Connect AppAuth 软件，包括：Google、OKTA、Ping 和我的产品 Gluu。
也可以看看：