oauth-2.0 - 使用 OAuth 访问 SPA 和 REST API 时，RBAC 的用户组成员身份应该存储在哪里

Question

我正在努力实现 oauth2 以保护将调用 REST API 的 Web 应用程序，并允许其他潜在客户访问相同的 rest API。我想使用基于角色的访问来控制从 API 返回的数据。
我将使用 Keycloak 作为授权服务器以及用户/组管理。

用例是

1. 我将使用公共(public)客户端 (SPA) 和 secret 的可能仅承载客户端 (REST API) 以及将属于这些组的组和用户创建 keycloak 领域
2. 用户将通过授权流程登录到 SPA，并将收到一个访问 token 。
3. SPA 将向 REST 服务发出请求 (XHR)，将 token 作为 Bearer token 传递，并根据用户所在的组检索数据或执行允许的操作。

我试图了解/最佳实践我应该在哪里存储用户所属的组列表。 SPA 和/或 REST 服务可以检索和传递的是访问 token 还是 ID token ，必须使用访问 token 和 userinfo 端点从授权服务器检索该数据。似乎 keycloak 将 JWT 用于访问和 ID token ，并且角色/组可以包含在两者中。我阅读了混合的建议，即访问 token 不应由 REST 服务读取并且仅用于证明用户已通过身份验证，但后来我看到它用于传递用户组。

我的另一个问题是，如果我想允许自动客户端访问无法使用授权流程的 REST API，最好的做法是使用客户端流程并在 keycloak 中加入该客户端并提供客户端 clientId 和 secret 以便能够检索访问 token 使用它来对 REST 服务进行身份验证(Bearer 身份验证 header )

更新

我还有几个后续问题，希望能弄清楚。

至于 ID token ，我认为 ID token 只应由验证用户身份的应用程序 (SPA) 使用，并将获取有关用户的信息(用户名、电子邮件和其他一些信息)关于声明和用户批准权限。可能是为了在应用程序中显示这些东西。 ID token 不应(永远不会)发送到 REST API 以检索数据。

另一方面，访问 token 不应在应用程序 (SPA) 中读取，而应在 API 服务器(Bearer $AUTH_TOKEN)的每个请求中使用，API 服务器验证 token ，然后检索用户的分组信息并返回允许的响应。

仍然不清楚的是，如果应用程序收到授权 token 并不意味着用户已通过身份验证。为什么我们需要 ID Token。

此外，如果访问 token 并不总是携带信息并且可能只是一个随机字符串，那么您如何知道用户的权限。我读到有两种类型的 token “标识符类型”和“自包含类型”。我猜测如果 token 是标识符类型，那么 REST 服务将必须向授权服务器发送请求以通过回顾 API 获取该信息(组/权限)。

找到两篇关于此的好文章:
https://darutk.medium.com/oauth-access-token-implementation-30c2e8b90ff0 .
https://darutk.medium.com/api-protection-by-id-token-3123481e96f2

Answer 1

您应该始终将授权信息放在您的访问 token 中，而不是 ID token 中。有关用户组的信息可以出现在 ID token 中，例如，如果您在客户端中需要它们 - 也许您想根据用户组等对某些信息进行颜色编码。

Another question that I have is that if I want to allow an automated client to access the REST API which won't be able to use authorization flow is it in the best practice to use client flow and on board that client in keycloak and provide the client clientId and secret to be able to retrieve access token use it to authenticate to the REST service (Bearer authentication header)

正如 Jan 指出的那样，客户端凭证流正是为此目的而创建的 - 这样后端就可以相互通信。这是一种对客户端进行身份验证的方法。

What is still not clear is that if an application received an authorization token doesn't that mean the user is authenticated. Why do we need ID Token.

正如您所写的那样 - 访问 token 适用于 API，ID token 适用于客户端。当然，当您的客户端获得访问 token 时，这意味着用户已通过身份验证，但许多客户端希望获得有关已通过身份验证的用户的其他信息，因此他们可以例如显示您的个人资料图像、您的用户名、知道您的电子邮件等。因此 ID token - ID token 为您提供有关经过身份验证的用户的信息，不仅证明他们已通过身份验证。如果您只需要证明用户已通过身份验证，那么访问 token 就足够了。

Also, if access token does not always carry information and could be just a random string then how would you know user's permissions. I was reading that there are two types of tokens “identifier type” and “self-contained type”. I am guessing that if the token is an identifier type then REST Service will have to send a request to the authorization server to get that information (groups/permissions) via retrospect api.

确切地说，如果您使用不透明的字符串作为访问 token ，那么 API 将必须对授权服务器执行内省(introspection)流程(RFC 7662 中定义的标准)以验证 token 并获取关联的授权信息(例如用户组等)。如果您担心您的服务和授权服务器之间的流量很大，您可以查看一个名为 Phantom Token flow 的模式。它利用 API 网关及其缓存来执行内省(introspection)而不是服务本身。我建议使用这种方法，特别是因为您说过您将有 3d 方客户端访问您的 API。最好不要与 3d 方集成商共享 JWT 访问 token 。

另请参阅这篇关于 API Security Best Practices 的文章，它可能会更清楚地说明这些东西。