OIDC 中的 OAuth2 角色答案

【问题标题】：OAuth2 Roles in OIDCOIDC 中的 OAuth2 角色
【发布时间】：2018-12-15 05:58:23
【问题描述】：

在 OAuth2 协议中，Client（OIDC 中的 RP）应用程序获取访问令牌，使其能够代表不同的服务（资源服务器角色） 资源所有者。

另一方面，在 OpenID Connect 协议中，Client 获得 2 个令牌（access 和 id 令牌）。现在，此客户端可以使用访问令牌从 UserInfo 端点获取用户声明。

OP（授权服务器）在这里扮演资源服务器的角色（就 OAuth2 而言），客户端代表用户获取用户数据吗？
客户端如何使用 ID 令牌？客户端是否将此 ID 令牌传递给资源所有者的用户代理（浏览器），然后，用户代理存储此令牌以启用 SSO（cookie）？
客户端（例如，与获得 ID 令牌的不同）是否必须在每次用户访问它时验证令牌（调用 OP 来验证它），或者客户端仅在它第一次被此令牌访问时才这样做，并且然后创建安全上下文，使其能够每次在 OP 中消除此验证请求？在这种情况下，如何实现这个安全上下文？
当客户端可以使用 ID 令牌访问 UserInfo endoint 时，除了获取用户声明以及为什么它与 ID 令牌一起发送之外，访问令牌的用途是什么？

【问题讨论】：

标签： oauth-2.0 openid-connect

【解决方案1】：

首先您必须了解令牌的用途。访问令牌是一种足以代表最终用户访问受保护资源的令牌。它由 OAuth 2.0 授权框架定义。现在拥有访问令牌不会对最终用户进行身份验证。它只是授权客户端应用程序访问资源。 OpenID Connect 引入了 ID Token。现在此令牌将由您的客户端应用程序使用。 Protocol define how this to be done，如果有效，您的客户端应用程序可以对最终用户进行身份验证。

问：OP（Authorization server）在这里扮演Resource Server的角色（就OAuth2而言），Client代表用户获取用户数据吗？

部分正确。 According to the protocol document，userinfo 端点 充当 OAuth 2.0 保护资源。

UserInfo 端点是一个 OAuth 2.0 受保护资源，它返回有关经过身份验证的最终用户的声明。为了获得有关最终用户的请求声明，客户端使用通过 OpenID Connect 身份验证获得的访问令牌向 UserInfo 端点发出请求。

问：客户如何使用 ID 令牌？客户端是否将此 ID 令牌传递给资源所有者的用户代理（浏览器），然后，用户代理存储此令牌以启用 SSO（cookie）？

如前所述，客户端必须验证 id 令牌并在此基础上对最终用户进行身份验证。 ID 令牌未与 SSO 连接。

问：客户端（例如，与获得 ID 令牌的不同）是否必须在用户每次访问它时验证令牌（调用 OP 来验证它），或者客户端仅在它第一次获得时才这样做由该令牌访问，然后创建安全上下文，使其能够每次都在 OP 上消除此验证请求？在这种情况下，如何实现这个安全上下文？

如果您使用 ID 令牌从受保护的端点消费，则令牌接收方应在接受之前对其进行验证。可以选择在适当的令牌验证后创建会话（会话不得延长令牌的生命周期）。

问：当客户端可以使用 ID 令牌访问 UserInfo endoint 时，除了获取用户声明以及为什么它与访问令牌一起发送之外，访问令牌的用途是什么？

访问令牌是您应该用来访问受 OAuth 2.0 保护的资源的令牌。一旦端点收到它，端点就可以根据授权服务器公开的令牌自省端点（Protocol definition of introspection）验证访问令牌。并且使用 Openid Connect，定义 userinfo 端点让任何拥有有效 id 令牌的一方都可以使用它。

【讨论】：

首先，感谢您的回答。问第二个问题时，我想到了 SSO。您能解释一下在这种情况下如何使用 ID 令牌吗？而且，在普通的 OAuth2 中，资源服务器是否总是在授权服务器的自省端点检查访问令牌？
正如我所说，SSO 与 ID 令牌无关。 ID 令牌旨在供客户端应用程序使用。 SSO 将主要基于 cookie（在身份提供者和用于完成登录的 Web 浏览器之间）。资源服务器可以随时检查访问令牌。但它可能会缓存它，甚至尝试在客户端和自身之间创建会话以避免自省开销
非常感谢。这意味着浏览器在与 OP 的会话中第一次访问的不同客户端（不是接收到 id 令牌的客户端）将必须访问 OP 以进行授权，然后 OP 检查浏览器会话，将验证用户而无需用户输入他的证书。然后 OP 是否会为这个其他客户提供新的令牌？另一个问题，您所说的“供客户消费”是什么意思？客户端是否仅使用此令牌来读取用户信息，也可以通过使用访问令牌访问 userInfo 端点来完成？那么，客户端之间没有传递 ID 令牌？
是的，OP 可以以这种方式运行。它与您看到使用 Google 按钮登录的方式非常相似，一旦单击，您就会看到跳过登录，因为您已经登录到 Google（假设是从 Chrome 浏览器）。是的 ID 令牌由客户端使用。由客户端对最终用户进行身份验证。但在某些情况下，它可能会在服务之间传递（例如：- 您客户的后端）
请您复习一下 Touffy 的答案吗？我认为其中许多是不正确或不精确的。

【解决方案2】：

如果您阅读了 RFC，我看不出您会对此感到困惑。

您想将身份视为一种“资源”服务吗？很好，但是此服务的身份验证与 RP 的身份验证不同，那么您的意思是什么？
客户端存在于用户代理中（我们谈论的是 SPA，对吗？）。如果 ID 令牌在客户端中，那么它在 UA 中（反之则不成立）。如果您正在考虑服务器端客户端，则无需将 ID 令牌转发给 UA，除非您希望 UA 将其传递给另一个客户端（例如，对于 SSO）。为了方便起见，有些 SSO 方案使用 ID 令牌，但这不是 ID 令牌的规定用途。
JWS 的全部意义在于您不需要调用 OP 来验证令牌。您只需验证签名。这可以由任何客户完成，无论他们是令牌的原始接收者，还是他们后来得到它。此外，ID 令牌不是用于对用户进行身份验证。将其用于 SSO 需要某种其他形式的安全性，例如将相关机密存储在客户端不会看到的仅 HTTP cookie 中。无论如何，即使您将 ID 令牌用于 SSO，也只会在登录请求中发送 ID 令牌。之后，Client 将获得自己的 access token 进行身份验证，不再使用 ID token。
访问令牌通常是短暂的（这意味着客户端必须定期联系 OP，这使 OP 有机会撤销访问权限）。访问令牌随每个经过身份验证的请求一起发送，因此它应该很小（即不包含对身份验证无用的用户信息）。

【讨论】：

1.我想清楚地了解 oidc 的工作原理。身份服务的身份验证有何不同？为什么Client有id token时需要使用access token来获取用户信息？ 2. 客户如何在他们之间传递 ID 令牌，而我有 SSO？也许这就是为什么 id 令牌不能用于获取有关用户的信息的原因，因为例如，另一个客户端（不是获得 id 令牌的客户端）不应该能够访问用户信息？ 3. ID token 怎么不是用来认证用户的？我明白这是它的主要目的。
1.身份验证对于 ID 服务是不同的，因为它是由 OP 提供的，并且 ID 令牌可以（并且通常是）作为登录过程的一部分提供，而不是稍后作为单独的请求提供。
我已经在 (4) 中解释了为什么不应该使用 ID 令牌进行身份验证。
3. ID 令牌的主要目的是告诉客户端用户是谁。另一方面，访问令牌说明了允许用户做什么，并且被设计为发送给 RP 并由 RP 进行验证。正如我已经说过的，访问令牌的有效负载和寿命较短是为什么它应该用于身份验证而不是 ID 令牌的原因。
@Mike 阅读您对 Kavindu 回答的其他评论，我想我看到了您一直以来所缺少的东西。 OAuth 和 OIDC 中的令牌是 JSON Web 令牌，通常已签名但未加密。它们包含 JSON 有效负载形式的数据。您不使用令牌来“获取”有关用户的信息，您只是从令牌中读取信息。