如何在不使用 OAuth 的情况下制作安全 API？答案

【问题标题】：How to make a Secure API without using OAuth?如何在不使用 OAuth 的情况下制作安全 API？
【发布时间】：2015-07-28 10:54:43
【问题描述】：

我的要求

我正在制作一个也有移动版本的网站。所以，我让它以 API 为中心。现在我想让我的 API 安全，而不需要 OAuth 的复杂性，因为我需要的安全性非常简单。我不希望任何有权访问 api 链接的人能够访问我的数据。

所以，我偶然发现了这篇文章http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/，这篇文章非常棒，并且消除了我的大部分疑虑。

现在，我正在尝试重新创建文章中的任何内容。我正在使用 Laravel 5 框架进行 PHP 开发。

我想确保该 API 仅被移动应用和网络版本使用，其他人没有。我看过类似的api链接

example.com/fetchallinformation&publicKey=<something>&Hashkey?<some_hash_key>

现在，我了解到这个密钥是使用 php 中的hash_hmac() 函数生成的。

我的方法

我有一张表，用于存储我的 api 用户的 publicKey 和 privateKey
URL 中的 HashKey 是在客户端对 privateKey 和 publicKey 进行散列生成，然后发送到服务器。因此，我将生成的 Hash 与 publicKey 一起发送到服务器。
在服务器端，我使用 publicKey 和 Hash。我从对应于 publicKey 的表中检索私钥并拥有它们并检查生成的哈希是否与客户端发送的哈希相同
如果相同，那么我允许他们，否则，我不。

我的困惑

我不确定这是否是正确的做法。
我们能否通过解密哈希得到已用于使用hash_hmac()生成哈希的数据？

【问题讨论】：

标签： php api security amazon-web-services hash

【解决方案1】：

URL 中的 HashKey 是在客户端对 privateKey 和 publicKey 进行散列生成，然后发送到服务器。因此，我将生成的哈希与公钥一起发送到服务器。

关闭，但不完全。正如您刚刚描述的那样，具有给定公钥的用户将在每个请求中发送相同的 hmac。这并不比“用户名和密码”更好。

附注：如果您不使用 https，那么您已经不安全，并且您为保护网站所做的任何其他措施都没有什么价值。

生成 hmac 签名的关键在于，它不仅验证用户是否拥有密钥，而且还验证特定请求是由该用户发出的，并且是在特定的时间窗口。两个背靠背的不同请求应该有不同的 hmac。今天的一个请求和明天的一个相同请求应该也有不同的hmac。否则，您将面临重放攻击。这意味着有关签名的当前时间或到期时间的信息，以及有关请求本身的信息，必须包含在通过 hmac 算法传递的信息中，否则您将无法完成很多工作。

对于特定用户在特定时间的任何给定请求，只能有一个可能的有效签名。 HMAC是不可逆的，所以不能在服务器端拆开签名，搞清楚请求的属性。

当然，如果您正在考虑在您的应用中嵌入该密钥，请记住，这种策略对于逆向工程来说可能相对微不足道。

这是一种可行的身份验证机制吗？当然。正如文章所指出的，Amazon Web Services 在其 API 上使用 hmac 签名，并且它们具有巨大的潜在攻击面……但这是否意味着您将以一种有意义的安全方式来实现它？不必要。总有人比你想象的更聪明、更狡猾、更坚定。

甚至亚马逊显然也意识到他们的签名版本 2 并没有想象中的那么强大，所以他们现在有了签名版本 4，它具有更复杂的算法，包括几轮散列和生成中间“签名密钥” " 派生自您的密钥、当前日期、特定 AWS 服务、AWS 区域和其他属性。 2014 年或更晚首次部署 Amazon S3 的区域根本不支持原始 Sig V2——而且似乎只能是出于安全意识来推动该决定，因为旧算法的计算成本较低，到目前为止。

在滚动您自己的安全机制时要小心谨慎。

如果您主要是想避免 OAuth 的学习曲线，我同意这在开始时很烦人，那么您可能是在做傻事。

【讨论】：

您所说的重放攻击可以通过在发送请求时在散列时添加时间戳和公钥来避免。所以，我想我可以实现这一点。我的身份验证的唯一用途是确保只有授权用户使用我的 api 链接。那么，对于这个简单的事情来说，OAuth 是不是太多了？对不起，我知道的不多，只是想知道。是的，我发现学习 OAuth 真的很烦人。你能推荐一些好的文档吗？

【解决方案2】：

如果这种方法对你有用，那肯定没问题，而且毫无疑问是安全的。

关于解密 - 由于 HMAC 的性质（哈希），它不应该被解密。 HMAC 被认为是非常安全的，你应该没有问题。你可以阅读更多关于How and when do I use HMAC? [SE Security]

【讨论】：

【解决方案3】：

我想确保该 API 仅被移动应用和网络版本使用，而没有其他人使用。

这是一个 OAuth 和 AWS 风格的签名身份验证都没有真正帮助解决的问题。两者都是关于验证用户，而不是应用程序。如果您有大量时间投入其中，您当然可以实施任何一种方法，但是在这两种情况下，您都需要在您的应用程序中嵌入一个“秘密”，并且一旦您将该应用程序提供给用户，您的秘密就不是真的是秘密了……

没有什么好方法可以满足您的需求。如果有人要花时间对您的应用进行逆向工程以了解如何直接访问底层 API，那么您在客户端对调用应用程序进行“身份验证”的任何其他操作也都可以进行逆向工程。

我建议您不要费心，而是将时间花在优化您的应用上，这样没有人想要绕过它并直接访问您的 API。 :)

【讨论】：