我正在编写一个使用keycloak作为其用户身份验证服务的应用程序。我有普通用户（从前端（Web浏览器）登录到keycloak）和服务用户，从后端（IIS上的PHP）登录。但是，当我从后端登录时，keycloak使用HS256作为访问令牌的签名算法，因此由于在领域和客户端设置中设置了RS256，因此拒绝它进行进一步的通信。为了解决这个问题，我想“假装是前端”来为我的服务用户获取RS256签名的访问令牌。
出于安全原因，我无法将HS256密钥提供给应用程序服务器，因为它是对称的，并且太多人可以访问服务器的代码。
我目前正在前端和后端使用相同的用户/密码/客户端ID /授权类型来调试问题，因此不会成为问题。
到目前为止，我还没有运气尝试过这些：
那么keycloak如何确定使用哪种算法对令牌进行签名？如果不同版本之间存在差异，我应该在哪里查看keycloak的代码？
编辑：澄清登录流程以及后端处理它的原因。
如果用户登录，将发生以下情况：
但是在某些情况下，第五步的数据是我领域中存在的用户列表。这样做的问题是，密钥斗篷需要具有查看用户角色才能列出用户，该角色仅存在于主领域中，因此我无法使用登录用户的令牌来检索它。
对于这种情况，我在主领域中创建了一个特殊的服务用户，该用户具有view-users角色，并获取如下数据：
这使得用户名列表实际上是公开的，但是所有其他数据仍对客户端隐藏-出于安全性/隐私原因，我想保留这种方式，因此我不能仅将服务用户的登录数据放在JS中前端变量。
在后一个列表中，步骤4是失败的步骤，因为步骤3返回了HS256签名的访问令牌。在前一个列表中，步骤2正确返回一个RS256签名的访问令牌。
谢谢你的澄清。如果可以的话，我可能会以不同的方式回答您的问题。当您专注于令牌签名算法时，我认为OAuth2流中存在关于其用法的错误，或者您面临一些误解。
后端和前端都使用“直接访问授予”（指OAuth2流Resources Owner Credentials Grant）这一事实，这是错误的主张，或者是您的体系结构中的错误。
如Keycloak自己的文档所述（但在OAuth.2官方参考中也略有不同）：
想要代表用户获取令牌的REST客户端使用“资源所有者密码凭据授予（Direct Access Grants）” 。这是一个HTTP POST请求，其中包含用户的凭据以及客户端的ID和客户端的机密（如果它是机密客户端）。用户的凭据在表单参数中发送。HTTP响应包含身份，访问和刷新令牌。
据我所见，您描述的应用程序和用例不需要此流程。
相反，我在您的流程（1）中看到的是授权代码流程...
Implicit Flow（Password Grant现在也不鼓励使用流）。因此，我认为所提出的交换（您的帖子中第一个顺序为第1至5点）在某些时候是无效的。
对于第二个流程（后端->列表用户），我建议进行两项修改：
允许用户轮询前端应用程序以获取用户列表，然后前端将要求后端将其返回。具有向客户提供服务帐户的后端view-roles将能够获取所需的数据：
Client (logged) --> Request list.users to FRONTEND app --> Get list.users from BACKEND app
(<--> Keycloak Server)
<----------------------------------------- Return data.
针对此用例，将Client Credentials Grant（流）用于后端<> Keycloak交换。该应用将具有service account您可以为其分配特定范围+角色的。它不能代表任何用户使用（即使您可以用另一种方式检索原始请求者也可以！），但是它将以完全安全的方式进行并且保持简单。您甚至可以Client为这些交换定义一个特定的bearer-only。
毕竟，如果您采用这种方式，则不必担心令牌签名或类似问题。这将根据计划，流程和相关方自动进行处理。我相信，通过错误地利用流量，您最终不得不处理棘手的令牌问题。据我说，这是根本原因，比着重于签名问题更有用。你怎么看？
我错过了什么还是我完全错了...？你告诉我。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句