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，而只是添加更多的"claims"在OAuth 2.0中获取有关用户的信息？ 2.我的流程描述正确吗？

- Ronaldo Lanhellas

Answer 1

我不知道你的方法是否有效，但你完全可以自己开发认证方式。毕竟，Facebook、GitHub等公司正是通过定制oauth2来完成认证的。由于存在太多的oauth2“认证”方式，如果您想更改提供程序，则无法轻松插拔。我相信这就是引入OpenID Connect的原因——建立在既有的oauth2授权模式基础上，以一种通用的方式连接和处理认证。使用OpenID Connect或不使用都可以......但如果不使用，您将会重新发明轮子。

- sdoxsee

Answer 2

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

1. 它引入了一个完全新的令牌 (id_token)，其语义与OAuth 2.0的access_token截然不同，采用标准化格式，客户端可以理解，而access_token对于客户端来说是不透明的。 2. 它 “扭曲”了客户端的角色，现在成为token(id_token)的"受众"(或:预期的接收者)，而access_token的受众仍然是远程实体(即资源服务器)，客户端只是后者的“呈现者”。

第二个条目是OAuth 2.0和OpenID Connect之间混淆的主要原因。

- Hans Z.

Answer 3

@sdoxee的回答解释得很正确。但是为了让OP更好地理解，我会添加更多信息。

现在许多身份提供者（例如：Azure AD）发布基于JWT的访问令牌。这些JWT访问令牌包含有关最终用户以及与JWT相关的验证详细信息（例如：令牌过期）的声明。以下是Azure AD OAuth 2成功响应的链接，其中强调访问令牌是JWT。另请参见JWT声明以查看它们如何解释这些声明。以下是示例：

family_name：用户的姓氏。应用程序可以显示此值。

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

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

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

再次强调，如@sdoxee所指出的，要在正确的位置使用正确的协议。在访问令牌中具有声明并不一定意味着您应该将它们用于身份验证。

- Kavindu Dodanduwa

---

当用户尝试将第三方网站的内容分享到Facebook时，会显示一个登录页面以授权访问，这不是认证过程吗？这是使用Oauth完成的吗？ - Ronaldo Lanhellas

这是资源所有者和授权服务器之间的身份验证过程。Facebook用户是资源所有者，而Facebook是授权服务器。资源是资源所有者的帐户。这是OAuth 2.0的事情。它不是客户端应用程序的身份验证（例如：共享内容的第三方网站）。 - Kavindu Dodanduwa

谢谢，现在有意义了。 - Ronaldo Lanhellas