OIDC中的OAuth2角色

Question

在OAuth2协议中，客户端（就OIDC而言，RP）应用程序获取访问令牌，从而使它能够代表以下用户使用不同的服务（资源服务器角色） 资源所有者。

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

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

Answer 1

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

问：OP（授权服务器）是否在这里充当资源服务器的角色（就OAuth2而言），并且客户端代表用户获取用户数据？

部分正确。 According to the protocol document，用户信息终结点充当受OAuth 2.0保护的资源。

  

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

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

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

问：客户端（例如，与获取ID令牌的令牌不同）是否必须在用户每次访问令牌时都要对其进行验证（请致电OP进行验证），或者只有在客户端第一次获得令牌时才进行验证通过此令牌访问，然后创建安全性上下文，使其可以每次在OP消除此验证请求？在这种情况下，如何实现此安全上下文？

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

问：当客户可以使用ID令牌访问UserInfo内码时，访问令牌除了用于获取用户声明外，还与访问令牌一起发送，为什么使用？

访问令牌是您用于访问OAuth 2.0受保护资源的令牌。端点接收到端点后，端点可以针对授权服务器（Protocol definition of introspection）公开的令牌自省端点验证访问令牌。借助Openid Connect，定义userinfo端点可以让具有有效id令牌的任何一方使用它。

Answer 2

如果您已阅读RFC，我不会感到困惑。

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