Mec*_*ind 7 oauth openid-connect keycloak
我正在使用人类用户和物联网设备在 Keycloak 中实现身份验证系统。
人类用户：通过 spa 访问系统并使用基于标准重定向的身份验证流程。
物联网设备：该用例涉及许多高价值设备，这些设备不具有交互性，需要将遥测数据传输到后端并访问自己的数据以及相关用户的数据。我当前的计划是使用资源所有者密码凭据授予，因为可以在配置期间使用凭据设置嵌入式系统。
我的想法是，这将使我能够使用 Keycloak 组和角色进行权限管理和用户 <-> 设备关联。
这种方法有什么本质上的错误吗？
\n\n我当前的计划是使用资源所有者密码凭据\n授予，因为可以在配置期间\n使用凭据设置嵌入式系统。
\n
从源码中可以读到：
\n\n\n资源所有者密码凭据授予类型适用于资源所有者与客户端具有信任关系的情况，例如设备操作系统或高特权应用程序。授权服务器在启用此授权类型时应特别小心，并且仅在其他流程不可行时才允许使用。
\n此授权类型适用于能够获取\n资源所有者\xe2\x80\x99s 凭据（用户名和密码，通常使用\n交互形式）的客户端。它还用于通过将存储的凭据转换为访问令牌，\n使用直接身份验证方案（例如 HTTP Basic 或 Digest\nauthentication）将现有客户端迁移到 OAuth：
\n
您的用例满足这些限制吗？
\n如果不是，请考虑使用客户端凭证授予：
\n\n\n对于机器对机器 (M2M) 应用程序，例如在后端运行的 CLI、守护进程或服务，系统会对应用程序而不是用户进行身份验证和授权。对于这种情况，典型的身份验证方案（例如用户名+密码或社交登录）没有意义。相反，M2M 应用使用客户端凭据流（在 OAuth 2.0 RFC 6749 第 4.4 节中定义），在其中传递客户端 ID 和客户端密钥来验证自身身份并获取令牌。
\n
因此，在后者中，您将使用客户端密钥，而不是使用用户名和密码进行身份验证。
\n\n\n我的想法是，这将使我能够使用 Keycloak 组和\n角色进行权限管理和用户 <-> 设备关联。
\n
您仍然可以向机密客户端添加声明并将其用于权限管理。
\n| 归档时间： |
|
| 查看次数： |
2383 次 |
| 最近记录： |