目标：
我想编写一个可以触发 Jenkins 作业的应用程序，它本身也可以针对 Crowd 服务器对用户进行身份验证。用户必须在单独的人群组中才能被授权对 Jenkins 采取行动。
设置：
我正在使用 Crowd2 插件针对 Atlassian Crowd 2.1 服务器对 Jenkins 用户进行身份验证。
我的想法：
现在，Jenkins 有两种远程执行方式：
Jenkins REST API（使用每个用户的令牌进行身份验证）
可以使用“TOKEN”以如下方式通过此调用触发构建：
JENKINS_URL/job/JOBNAME/build?token=TOKENJenkins CLI（使用 SSH 密钥进行身份验证）
可以通过命令行工具触发构建，使用 SSH 私钥对用户进行身份验证。
令牌方法（REST API）...
... 要求我的应用程序知道 API 令牌。
如何绕过 API 令牌限制？
将 API 令牌存储在 Crowd 中？
Crowd2 Jenkins 插件可以将 Jenkins API 令牌存储为群组属性（可以存储在群组用户目录中的用户定义属性），这是一种方式。尽管我认为这可能是一个安全漏洞，因为该属性可能是从在 Crowd 注册的所有其他应用程序中检索到的（这将使他们能够代表用户执行 Jenkins 作业）。
问：好的方法和足够的安全？在我看来，这还不够安全。
使用我的应用程序人群令牌对 Jenkins 进行身份验证？
我还尝试通过 Crowd 的 API 生成人群令牌，然后使用该令牌作为 Cookie 请求 Jenkins REST API，希望 Jenkins crowd2 插件针对 Crowd 验证传递的 Crowd 令牌。但它不起作用（当使用我的浏览器中的人群令牌时，通过检查 Firefox 中的页面信息，它当然可以工作）。
我不确定这种方法（如果 crowd2 插件会检查传递的令牌）是否存在安全漏洞，以及 crowd-token 机制是否设计为以这种方式工作。不过我敢肯定，这可能会对 Jenkins 的性能产生负面影响，因为每个 API 请求都必须检查令牌是否有效。
问：好的方法和可能吗？
CLI 方法...
...要求我的应用程序知道在 Jenkins 注册的 SSH 私钥。
如果 Jenkins 支持添加 SSH 密钥，这将是一个好方法。我的应用程序可以生成一个 SSH 密钥对（带有随机）密码，并代表用户在 Jenkins 中自动存储公钥。
我认为这是正确的方法，即使它需要扩展 Jenkins 并且可能需要扩展身份验证插件。
问：这种方法是否可行且足够安全？
问：还有其他方法吗？
我认为 Jenkins 应该实现一个 OAuth 端点来进行授权（如果是 crowd 插件，它必须将授权委托给 Crowd）或者将用户管理与其核心完全分离。我错了吗？
如果有必要，请帮助我改进这个问题。我可以想象我已经混合了两个问题，并且目标描述得不够清楚。
注意：在创建后约 1 小时编辑此问题（请参阅我的第 1 条评论）。