OAuth2.0 和 OpenID Connect 令人困惑

Question

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

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

在 OAuth 2.0 客户端从授权服务器检索 ACCESS_TOKEN 之前，该服务器应验证用户是否允许，这是 OAuth 2.0 不关心的身份验证过程。

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

我的问题是：

1. 为什么不忽略 OpenID Connect 并在 OAuth 2.0 中添加更多“声明”来获取有关用户的信息？
2. 我对流程的描述正确吗？

Answer 1

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

Answer 2

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

1. 它引入了一个全新的令牌 ( id_token)，其语义与 OAuth 2.0 完全不同，access_token以及客户端可以理解的标准化格式，而不是access_token对客户端不透明的格式

2. 它“扭曲”了客户端的角色，现在成为令牌（即 ）的“受众”（或：预期接收者），id_token而 的受众access_token仍然是远程实体（又名资源服务器）并且客户端只是后者的“主持人”

第二项是 OAuth 2.0 和 OpenID Connect 之间混淆的主要根源。

Answer 3

@sdoxee 答案正确地解释了事情。但我添加了更多信息以供OP 理解。

\n

如今，许多身份提供商（例如：Azure AD）都会颁发基于 JWT 的访问令牌。这些 JWT 访问令牌确实包含有关最终用户的声明以及 JWT 相关的验证详细信息（例如：令牌过期）。以下是 Azure AD OAuth 2 成功响应的链接，其中突出显示访问令牌是 JWT。另外，请参阅JWT 声明，了解他们如何解释这些声明。示例如下，

\n

\n

family_name ：用户\xe2\x80\x99的姓氏。应用程序可以显示该值。

\n

Give_name：用户\xe2\x80\x99 的名字。应用程序可以显示该值。

\n

\n

人们可以考虑对访问令牌中存在的声明进行身份验证，但这并不符合协议。大多数声明和用户信息将是特定于实施者的。此外，根据协议定义，这两个令牌（id 和 access）有两个不同的受众。

\n

\n
• ID 令牌用于客户端，用于验证和身份验证。
\n
• 访问令牌用于 OAuth 2 受保护端点。
\n

\n

再次强调，正如 @sdoxee 所强调的，在正确的地方使用正确的协议。在访问令牌中拥有声明并不一定意味着您应该使用它们进行身份验证。

\n