现在，我了解了OpenID Connect并感到有些困惑。
OpenID Connect和通过OAuth2使用身份API有什么区别？仅仅是我有一个标准的配置文件API，这样我就不必担心会返回
"email"还是"emails" JSON？ 或者还有更多的功能，这使OpenID Connect方法比我的第一种方法更安全吗？
#1 楼
OpenID connect将为您提供访问令牌和ID令牌。id令牌是JWT，包含有关已认证用户的信息。它由身份提供者签名，可以在不访问身份提供者的情况下进行读取和验证。
另外，OpenID connect标准化了oauth2可以选择的很多方面。例如作用域，端点发现和客户端动态注册。
这样可以更轻松地编写代码，使用户可以在多个身份提供者之间进行选择。
评论
您确定您的语句“ OpenID connect将为您提供访问令牌和ID令牌”。是正确的？我以为应用程序可以有一个id_token并与其他应用程序共享，然后从该应用程序获取访问令牌。 OIDC依靠OAuth2协议，但不一定要两者兼得。虽然，它可能在大多数时间发生。
–托马斯·兰恩
18/12/17在18:08
“ OpenID connect将为您提供访问令牌和id令牌。” >>在大多数情况下，这是正确的，而且通常是这样处理的。您发出一个包含“ token id_token”作为responseTypes和“ openid”作为范围的请求，这将同时返回访问令牌和id令牌。 ID令牌用于客户端，而访问令牌对于客户端则是不透明的，并且应在请求中传递给资源服务器以进行保护，例如API或其他后端。
– Mathias Conradt
19年4月8日在9:30
“我认为一个应用程序可以具有一个id_token并与其他应用程序共享，然后从该应用程序获取访问令牌。” >>如果您要这样做，则不要将ID令牌交换为访问令牌。两者都是授权服务器/ IdP的问题，而不是另一个应用程序或资源服务器的问题（尽管授权服务器和资源服务器有时可以相同）。
– Mathias Conradt
19年4月8日在9:31
#2 楼
OAuth仅提供并且仅应使用访问令牌提供授权。 OpenID connect建立在OAuth 2上，以提供用户身份验证信息。但是，它不会为您提供比OAuth更健壮的实现（因为它使用OAuth并添加了与OpenID提供程序的一些额外交互）。OpenID Connect 1.0是一个简单的身份层，位于OAuth 2.0 [RFC6749]协议的顶部。它使客户端能够基于授权服务器执行的身份验证来验证最终用户的身份，并以可互操作且类似于REST的方式获取有关最终用户的基本配置文件信息。
OpenID Connect核心1.0-草案17
OpenID connect为您提供了一种获取用户身份的“标准”方式。如果您使用OAuth和API，则应针对每种资源调整您的请求，这些资源可能并不总是提供相同的信息，或者可能随时间变化。从概念上讲，您可以使用OAuth来使用API，而不是对用户进行身份验证。
作为背景，OAuth 2.0授权框架[RFC6749]和OAuth 2.0 Bearer Token Usage [ RFC6750]规范为第三方应用程序提供了一个通用框架，以获取和使用对HTTP资源的有限访问权限。它们定义了获取和使用访问令牌访问资源的机制，但没有定义提供身份信息的标准方法。值得注意的是，如果不对OAuth 2.0进行概要分析，则无法提供有关最终用户身份验证的信息。 OpenID Connect Core 1.0-草稿17
请注意，OpenID connect为
id_token提供了有关用户的一些信息。但是，如果您需要全部信息，则仍然需要access_token来请求OpenID提供程序获取userinfo（这是我第一次看到它时感到困惑）。这表明从API或OpenID提供程序请求用户信息使用的方法几乎相同。请参阅草稿中的5.3.1. userinfo request。评论
这个答案是绝对正确的。只是想指出一个小问题：“但是，如果您需要全部信息，则仍然需要access_token来请求OpenID提供程序获取用户信息” >>不一定是这种情况，具体取决于授权服务器/ broken used：还可能已经在ID令牌= JWT令牌或甚至其他任何使用自定义声明的信息中包含了完整的个人资料；例如auth0.com/docs/tokens/id-token#add-custom-claims。然后，您不再需要执行/ userinfo请求。
– Mathias Conradt
19年4月8日在9:34
#3 楼
OAuth是一种授权协议，提供了一种授权访问受保护资源的方法。授权过程的副产品是对用户进行身份验证。从技术上讲，OAuth不必向您提供有关该用户的任何信息。它提供的验证是用户已授予应用程序访问某些数据的权限。这受授权授予的范围支配。
OpenID Connect提供了一种方法，使应用程序可以检索有关已认证用户的信息。最重要的是，它提供了一定程度的保证，即该信息是有效的（就授权服务器而言）。然后，可以使用它来促进身份联合。
过去，OAuth通过授予允许访问用户身份信息的范围来实现联合。 OpenID Connect对该范围进行了标准化。
评论
外部提供商仍需要支持开放ID吗？您不能仅仅在现有的oauth 2提供程序之上实现开放ID作为这些外部服务的客户端。
– CMCDragonkai
17年3月13日在6:22
#4 楼
OpenID Connect是OAuth2的配置文件...定义了一种体系结构，该体系结构使人可以授权身份提供者向客户端（网站/移动应用程序）发布某些用户声明。OAuth2提供了资源所有者IAM专家正确地将密码凭据授予称为“恶魔”。
OpenID Connect API的常见模式包括三个步骤：
1）获取代码
2 ）获取诸如
access_token，refresh_token和id_token之类的令牌3）获取包含诸如用户名，电子邮件之类的声明的用户信息。
id_token的模式是JWT，在OpenID中定义连接范围以及其他许多细节。
使用OpenID Connect的另一个原因是，存在针对移动软件（至少是IOS和Android）进行集中身份验证的安全解决方案。 Google定义的当前最佳做法是使用新的安全功能，以阻止移动应用程序在Web视图中查看Cookie或凭据。 Google发布了AppAuth IOS和Android库，因为它们确实不希望您泄漏Google凭据！在撰写本文时，有多个支持Google OpenID Connect AppAuth软件的OpenID提供程序（又名IDP ...），包括：Google，OKTA，Ping和我的产品Gluu。
另请参见：
本机应用程序的OAuth 2.0 draft-wdenniss-oauth-native-apps-02
IOS的AppAuth
Android的AppAuth
#5 楼
不建议将OAuth用作身份验证方法，而是将其显式设计为委托授权方法。Facebook使用OAuth作为身份验证方法，但进取心的人发现了如何从Facebook窃取
access_token-完整的博客条目OpenID Connect使通过这种机制窃取访问令牌变得更加困难。
评论
感谢您的链接-必须检查有什么区别...
–rd mueller
15年12月24日在12:05
好。阅读博客条目。对我来说，这听起来像是Facebook实现了一些安全漏洞，但并未破坏OAuth ...因此，当我使用OAuth方案（必须在服务器之间验证访问令牌）时，博客中描述的问题就无法解决。尚未露面...我仍然坚信OAuth（以正确的方式实施）非常好...
–rdmueller
15/12/26在22:06
这个更好地解释了为什么使用OAuth作为身份验证机制会造成安全漏洞：thread-safe.com/2012/01/…
–rickricktie
17年3月15日在10:19
#6 楼
Open ID Connect建立在OAuth的顶部，因此更加健壮。 OAuth是仅用于授权的协议，开放ID连接与OAuth非常相似，但它也结合了OAuth的功能。您可以使用此协议开始RP和IP之间的通信，它们是OAuth协议中的各种漏洞，这就是为什么最好使用Open Id Connect的原因。评论
知道这个答案为什么会被拒绝会很有趣...
–rdmueller
13-10-11在18:18
您指的是哪些漏洞（诚实的好奇心）。我正与OP一样在苦苦挣扎。尽管我熟悉使用简单Bearer令牌可能进行的会话劫持和MiM重播攻击，但oAuth2（基于Openid Connect的基础）已经在进行身份验证。这些是您所指的漏洞吗？
–Geert-Jan
13-10-29在20:48
7年后... OIDC肯定不会解决这些漏洞吗？毕竟，您仍然具有访问令牌，并且它们仍在执行OIDC的OAuth2中应该执行的相同操作？在我看来，如果您在OAuth2的实现中存在缺陷，那么将OIDC置于顶层将无法解决这些问题。
–Seer
20-05-28在8:47
评论
好吧，我不了解“ OpenID Connect”，我将其理解为“ OpenID” +“ Connect”。我确定您已经检查了以下内容：softwareforallseasons.blogspot.fr/2011/10/…+我建议您编辑问题，以使其读取OAuth 2.0而不是OAuth。@Aki：是的，我看过博客文章，但什么也没做。
@Ralf：据我所知，您可以使用oauth来构建应用，并授权共享或不共享链接到用户帐户的特定资源。使用openid connect，它变得更容易，提供程序不必在oauth之上实现自己的层即可处理它，并且客户端具有访问数据的标准方法。
“我只是使用每个提供商的身份/配置文件API来获取用户的经过验证的电子邮件地址。”这意味着您需要限制允许的提供者的集合。任意提供者不能保证验证。或者，您可以拒绝与提供商域不匹配的电子邮件地址。
如oauth.net上的一篇文章所述：OAuth 2.0不是身份验证协议。它实际上是授权框架。如果要进行身份验证，他们建议使用OpenID Connect（基于OAuth 2.0）。