使用OAuth控制对我们API的不受信任的第三方服务的访问

时间:2019-06-20 15:38:15

标签: api oauth-2.0 jwt

我需要保护对不受信任的第三方服务使用的API的访问。我目前的调查使我不得不使用grant_type=“client_credentials”来传递我为Idenity服务器中的第三方设置的clientId和客户密码。但是,此流程似乎仅适用于受信任的客户端的机器对机器(MTM)连接。

我可以理解为什么:如果我将这个流程与HS256一起使用,那么我可以看到一个明显的安全漏洞:JWT是使用共享对称密钥签名的。这意味着没有任何事情可以阻止第三方使用此密钥生成并签署自己的JWT令牌,并完全规避认证服务器。但是,如果我使用RS256,那么该缺陷就不存在,因为不受信任的一方只能访问公钥,因此他们无法创建自己的签名JWT。

[EDIT] :我现在知道您不应该在客户端验证令牌,因为不需要令牌,这意味着它们不需要密钥,因此此“缺陷”是辩论。

我的主要问题是:这是针对我的用例的正确方法,还是我应该在此处使用其他OAuth流程?我读过的所有内容都表明,client_credentials授予类型仅应在客户端是资源所有者且受信任时使用,这不是我的情况-但是,然后他们声明您必须使用隐式或授权代码-既需要用户参与,也不适用于我的用例。

1 个答案:

答案 0 :(得分:1)

因此,我假设您不希望客户端在连接/验证服务时手动输入任何密码或密码。如果是这样,请继续阅读,否则我会完全误解了您的问题。

一件事是您的客户机密将始终处于被泄露的风险中。您无能为力-就像您的用户密码被盗用一样。是他们的错。

您可以采取一些措施来提高安全性(尽管这会给您使用API​​带来一定程度的不便-但您始终可以添加SDK供第三方使用)。但是首先,当您说不信任时,它可能意味着两件事:

  • 非恶意和不受信任(NMU):第三方在有意访问您的服务时将不会做任何“不好”的事情。大多数消费者都会在这里。
  • 恶意且不受信任(MU):第三方可能会做“坏事”。你不知道。如果发生这种情况,那完全是他们的错,应该责怪他们。不是你。

无论哪种方式,您都可以简单地做到这一点,以便他们继续为每个API请求使用您提供的密码。这是最简单的方法-但是,当然会增加这个秘密被盗的机会。

如果您想进一步提高它的安全性,则可以使用此密码向该客户端颁发长期访问令牌。如果使用JWT,则签名密钥可以对称并保留给您-因为他们不需要在自己的身边验证令牌。他们只是在每个请求中使用它。这样会有问题,您或他们将如何知道此访问令牌是否被盗?另外,使用寿命长的JWT通常不是一个好主意,因此,如果您是我,我会为此使用非jwt令牌。

如果要使其更高级(最安全):该服务将使用您提供给他们的秘密对自己进行身份验证。然后,您可以向他们颁发短期访问令牌和长期刷新令牌。他们将使用此访问令牌进行所有常规API调用以进行身份​​验证,并在该API过期时使用刷新令牌访问特殊的API端点,以获取新的访问令牌。此外,您可以在刷新令牌每次点击刷新API时进行更改-这还将使您和他们能够检测到令牌被盗! (请参见this)。如果决定采用这种方法,则还必须注意this blog中提到的一些竞争状况和网络故障问题。另外,您还可以更改JWT签名密钥,因为您有一个刷新令牌可以回退!但这将为您提供最安全的解决方案。

请注意,第三方服务可能属于MU类型,因此您无能为他们保护服务的安全–根据服务的用途,其数据和“帐户”将受到影响。

希望此答案对您有所帮助!随时在Discord上给我发消息,以聊天更多有关此的信息。我在this server上找到了用户名rp#5569。