探索第三方 API 服务的身份验证方法:优点和缺点

文章探讨了三种常见的API身份验证方法:简单的API密钥、登录+access_token和密钥交换。简单的API密钥实现容易但安全性较差;登录+access_token增加了一定的安全性,但需管理生命周期;密钥交换提供最高安全性,但设置复杂。对于不同敏感程度的服务,作者建议权衡安全与性能。

探索第三方 API 服务的身份验证方法:优点和缺点

赛斯·法特的相片
赛斯法特
·
2023 年 3 月 18 日
·
4分钟阅读

嗨,大家好,

我们中的大多数人已经使用多个第三方 API 服务来实现您的业务逻辑。是的,他们中的大多数都有不同的身份验证方式。

在这篇文章中,我将拆解一些流行的方式。让我们开始吧。

简单的 API 密钥
80% 的服务都是以这种方式使用的。我们只需索取 API 密钥(从管理仪表板)然后 boom,我们可以立即使用这些服务。

我们需要在标头、URL 参数或 POST 正文中提供 API KEY。

$http->get('https://awesome-service.com/v1/api/awesomeness', [
    'headers' => [
        'X_API_KEY' => 'generated_api_key_here',
    ],
]);

优点:

最简单的方法,实现很简单。

API 消费者很高兴,因为它也非常易于使用。

API KEY 将永远可用。

缺点:

API KEY 将永远可用(笑)。检查下一个。

拥有最差的身份验证安全性。如果你公开了你的密钥,每个人都可以使用你的密钥访问该服务(如果该服务包含敏感数据、金钱等,那将是一个真正的危险)。以及速率限制。

为避免这种情况,请在后端服务中创建自己的包装层来处理第 3 方请求。切勿返回/使用 FE/Mobile 中的密钥。

💯 如果服务提供了 SDK 包(用于 PHP、Node、…)- 节省时间嘿嘿。
或者,服务提供商也应该有白名单/后备 IP 地址。

一旦安全问题得到解决,那么它始终是我的首选解决方案。

简单登录以保留 API 密钥
与 about 相同,但还有 2 个改进:

我们可以索取 API 密钥。但此 API 密钥仅用于login(保留另一个可用于请求其他端点的 API 密钥 - 我将其称为access_token)

将access_token有一个寿命(30m,1h,…)

所以我们的代码会是这样的:

$dynamicToken = $http->post('https://strict-service.com/v1/api/auth', [
    'login_id' => 'seth.tran',
    'api_key' => 'generated_api_key_here',
]);

$http->get('https://strict-service.com/v1/api/classes', [
    'headers' => [
        'X_API_KEY' => $dynamicToken,
    ],
]);

优点:

比第一点更严格的安全性。

API 密钥现在有生命周期。

缺点:

在我们的后端服务中,我们需要添加生命周期检查(以便在请求令牌是否过期之前刷新)

如果 SDK 可用并覆盖它,那么💯
密钥交换
这种方式也非常严格。它还伴随着第一点,我们仍然需要一个生成的 API 密钥(用作标识符)。

这将涉及 1 个或多个密钥,例如 SSH、GPG、…甚至 SSL 证书(笑)。

首先,双方将共享公钥。然后导入它。

当向服务发出任何 API 请求时,我们的 BE 服务需要:

使用我们的私钥和他们的公钥来加密负载。

使用生成的 API 密钥进行调用。

一旦我们收到响应负载,我们可能需要:

解密有效载荷(上面的相同密钥方法)

$encryptedPayload = GpgService::forBankService()
    ->encrypt([
        'to' => [
            'name' => 'Seth Phat',
            'account' => '01010101010101',
            'swift_code' => 'ABCXYZ',
        ],
        'amount' => 100.00,
        'currency' => 'USD',
    ]);

$http->post('https://bank-service.com/v1/api/transfer', [
    'headers' => [
        'X_API_KEY' => 'my_generated_token',
    ],
    'body' => $encryptedPayload,
]);

很严格,对吧?

优点:

最安全的方式。数据将始终在两端加密。
缺点:

花很多时间来设置(在我们的基础设施中,在服务端,…)。大约需要一两个星期是正常的。

我们的 BE 服务需要实现加解密逻辑。

相信我,一旦你处理了这个,性能就不会很好。
大多数遵循这种方式的服务不会提供任何 SDK 包。只有文档。

根据服务的不同,我们必须重新生成密钥/SSL 证书(有些每年一次,有些每 5 年一次,…)

结论
个人选择:

对于不包含敏感数据的普通服务,我总是选择第一点(当然有多个安全选项)

对于敏感服务:安全优于性能 - 密钥交换。

你会选择什么?

呵呵,加油!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值