以下身份验证流的安全风险

Question

假设甲方有很多客户(其中一个叫客户X)，数据在甲方。

甲方允许客户X从他们的API中获取数据。为了做到这一点：

• 客户X下载client_id和client_secret
• 客户X使用client_id和client_secret访问/auth端点
• /auth端点返回令牌
• 客户X现在使用授权头中的令牌(授权:无记名YOUR_TOKEN_HERE)来命中API端点

在此之前，这对我来说是有意义的。

现在，假设我们包括乙方，它希望代表客户X访问甲方的数据。甲方建议做的是：

• 客户X下载client_id和client_secret
• 客户X前往乙方并在那里开设client_id和client_secret商店
• 乙方使用来自客户X的client_id和client_secret到达/auth端点
• /auth端点返回一个令牌。
• 乙方现在使用授权头中的令牌(授权:无记名YOUR_TOKEN_HERE)代表客户X访问API端点

在我看来，客户X把甲方的client_id和client_secret交给乙方似乎有点不安全。

Answer 1

要确定某个设计是否“安全”，必须参考应用程序的威胁模型(该模型应解释甲方和客户X的风险偏好)。

但是是的，根据客户X和乙方之间的关系，至少可以看到三种潜在的安全威胁：

• 欺骗:使用client_id/client_accepted对，乙方可以识别为客户X。这完全可能是客户X有意/接受的。
• 信息披露:乙方可获取甲方向客户提供的任何敏感信息

尽管如此，通常，甲方没有办法限制谁与客户X分享他们的令牌。这通常是通过服务的条款和条件来完成的。人们想到的一个例子是在线预算应用程序，它需要访问银行账户来跟踪支出，并且过去需要用户的银行凭证。这显然是反对大多数(所有？)银行的T&C，然而，许多用户说，预算应用程序将传递他们的证书无论如何。

有一点相关，但甲方在试图减轻上述风险时可以使用的一种常见方法是将客户X视为不值得信任的客户。这意味着，例如：

• 不使用client_id/client_secret作为唯一的auth因素，并且需要额外的2FA
• 一旦客户X的行为似乎发生了变化，就立即清除令牌(要么是因为它们连接到不同的IP/用户代理/等等)。