Oauth 2.0 OAuth2.0和OpenID连接

我对使用OAuth 2.0作为授权方法和使用OpenID Connect作为身份验证方法感到困惑

据我所知，OAuth 2.0只是一种授权方法。换句话说，这是请求访问令牌并接收该访问令牌的过程，如下图中黄色椭圆所示：（简化）

在OAuth 2.0客户端从授权服务器检索ACCESS_令牌之前，此服务器应验证用户是否允许它，并且这是OAuth 2.0不关心的身份验证过程

当混合中包含OpenID Connect时，它也允许使用身份验证方法，但据我所知，OpenID Connect只是在JWT令牌中添加了一个“声明”，用于保存有关使用该服务的用户的信息，如：电子邮件、姓名和其他信息

我的问题是：

为什么不忽略OpenIDConnect，在OAuth中添加更多的“声明” 2.0以获取有关用户的信息

我对流程的描述正确吗

---

我不知道你的方法是否有效，但你完全可以自由使用自己的身份验证。毕竟，这就是Facebook、GitHub和其他许多人通过定制oauth2所做的。最终出现了如此多的oauth2“身份验证”方法，如果您想更改您的提供程序，它永远不会是即插即用的。我相信这就是为什么引入OpenID connect的原因——这是一种在已建立的oauth2授权模式基础上连接和推理身份验证的常用方法。使用OpenID连接或不使用……但如果不使用，您将重新发明轮子。

@sdoxee正确地回答了问题。但我要补充更多的信息让OP了解

如今，许多身份提供商（例如：-Azure AD）发布基于JWT的访问令牌。这些JWT访问令牌确实包含关于最终用户的声明以及与JWT相关的验证细节（例如：-令牌过期）。下面是Azure AD O的链接，其中突出显示访问令牌为JWT。另外，看看他们是如何解释这些说法的。样本如下：

family\u name：用户的姓氏。应用程序可以显示此值

给定名称：用户的名字。应用程序可以显示此值

可以考虑在访问令牌中的声明上构建身份验证，但这并不符合协议。大多数声明和信息都是特定于实现者的。此外，根据协议定义，这两个令牌（访问和id）具有两个不同的受众。ID令牌用于客户端、验证和身份验证。访问令牌用于OAuth 2受保护的端点

---

同样，当@sdoxee高亮显示时，在正确的位置使用正确的协议。在访问令牌中拥有声明并不一定意味着您应该使用它们进行身份验证

OpenID Connect不仅“在JWT令牌中添加声明”，而且：

它引入了一种全新的令牌（

id\u-token

），具有完全不同的特性 语义不同于OAuth 2.0

access\u令牌

和客户机理解的标准格式，而

access\u令牌

对客户机来说是不透明的

它“扭曲”了客户端的角色，现在成为令牌（即

id\u令牌

）的“受众”（或：预期接收者），而

access\u令牌

的受众仍然是远程实体（又称资源服务器），客户端只是后者的“呈现者”

---

第二项是造成OAuth 2.0和OpenID Connect之间混淆的主要原因。

当用户试图将第三个站点的内容共享到Facebook时，在授予访问权限之前会显示登录页面，这不是身份验证过程吗？这是由Oauth完成的？这是资源所有者和授权服务器之间的身份验证过程。Facebook用户是资源所有者，Facebook是授权服务器。资源是资源所有者的帐户。这就是OAuth2.0。这不是客户端应用程序的身份验证（例如：-共享内容的第三个站点），谢谢，现在有意义了