我正在维护SReview,这是一个基于mojolicious的webapp,需要运行许多需要更改数据库状态的后台任务.这些作业需要大量的CPU时间,并且有很多这样的工作,因此根据安装的大小,让多台机器运行这些后台作业可能是明智的.即便如此,有权访问数据库的计算机数量也相当有限,所以目前我让他们使用直接的PostgreSQL连接直接访问数据库.

这有效,但有时后台作业可能需要在恶意网络的另一端运行,因此可能不太需要额外的开放网络端口来进行数据库访问.因此,我正在考虑实现某种基于Web的RPC协议(可能是使用JSON的东西),并使用OAuth2来保护访问.但是,我之前从未详细讨论该协议,并且可以使用一些指导来确定使用哪个授权流程.

有两种方法可以将所需的凭据提供给运行这些后台作业的计算机：

>作业调度程序可以为后台作业指定环境变量或命令行选项.然后,这些将以可以假定为安全的方式传递给实际运行作业的计算机.但是,这意味着在某些情况下,作业调度程序本身也需要使用OAuth2进行身份验证,最好是以可以随意重新启动的方式进行,而无需一次又一次地进行身份验证.
>由于运行作业的计算机数量可能相当有限,因此应该可以为每台计算机创建计算机凭据.在这种情况下,能够在销售机器上并行运行多个会话是很重要的.

哪个授权流程最能支持这两种模型？

最佳答案 从您的场景概述可以清楚地看到系统之间发生了交互.没有最终用户(人类)用户交互.

首先,鉴于您的应用程序在安全环境(已关闭)中执行,它们可被视为机密客户端. OAuth 2.0 client types详细解释了这一点.在此背景下,您可以为每个分布式应用程序组件发出客户端ID和客户端密钥.

关于拨款类型,首先我欢迎您熟悉所有可用选项.这可以通过Obtaining Authorization部分来完成.简单来说,它解释了应用程序获取令牌(特别是访问令牌)的不同方式,这些令牌可用于调用OAuth 2.0受保护的端点(在您的情况下为RPC端点).

对您而言,最佳授权类型为client credential grant.它适用于与OAuth 2.0受保护端点具有预先建立信任的客户端.与其他授权类型相比,它不需要浏览器(用户代理)或最终用户.

最后,您需要使用OAuth 2.0授权服务器.这将注册不同的分布式客户端并向其发出客户端ID,秘密.当客户端需要获取令牌时,它们将使用令牌端点.并且RPC端点的每个客户端调用都将包含一个有效的访问令牌,您可以使用令牌内省(或任何特定的所需方法)进行验证.