18

我一直在寻找一种方法来保护我的 RESTful API。这看起来很简单，但似乎没有那么简单。首先，我正在编写一个连接到 Play Framework 服务器的 iOS 应用程序。这些都与 Google、Facebook、Twitter 或 LinkedIn 没有任何关系（我知道这很令人震惊）。哦，我目前的计划不需要自定义应用程序来使用我的 API，它暂时只是我的应用程序。

基本认证

看起来很简单的是一个基本的用户/传递一个 /auth 方法来管理一个 cookie 会话。这可能会引起一些抱怨太简单或太弱，但大多数情况下它将身份转移到快速验证的会话密钥。我最初的设置是每天使会话过期，但这导致 iOS 应用程序每天强制登录被证明是一件烦人的事情。

身份验证

我在 iOS 板上发布了一个问题，并收到了一个直截了当的 OAuth 指示。我对 OAuth 的研究开始了，但天哪，这太复杂了，而且似乎没有任何服务器端示例……只是很多人抱怨它是多么令人沮丧。所有客户端示例都显示连接到 Google、Facebook、Twitter 和 LinkedIn。哦，乔伊！

在看了 Eran Hammer 对 OAuth1 和 OAuth2 的吐槽之后，继续下去似乎没有结果，他的 OZ 想法（看起来很干净）在 node.js 中还只是处于早期阶段。

问题

所以，我向广大 StackOverflow 社区提出的问题是……您如何保护您的 REST API？

4

4 回答 4

7

我建议考虑最大玩家使用的方法，即 Amazon Web Services 或 Windows Azure - HMAC。尽管它在实施中并不舒适，但您可以看到它是值得信赖的技术。

一般的想法是在 iOS 中使用密钥对请求的部分（即标头）进行签名，并尝试在 Play 应用程序上重新计算它以验证该请求是真实的且未被操纵。如果它不会失败，您可以（几乎）确定，这是从使用有效密钥的某人发送的。

查看Windows 的文档 以了解概念（我认为对于常见任务，您可以使用较少数量的元素用于签名）。

还有其他有趣的帖子（基于 AWS 身份验证）更好地描述了整个过程。

编辑

当然，您应该意识到 iOS 中的身份验证和保护 API 请求是不同的事情，即使您的会话每 15 分钟到期一次，您也不能确定有人不会偷听然后能够发送来自外部的虚假请求。签署每个请求应将风险降至最低。

另一方面，如果您为签署请求准备明确的规则并编写简短的文档（我什至为您自己推荐），您可以将其交付给其他开发人员，他将能够在（几乎) 任何支持 SHA256 的平台，因此您将准备好从 3-rd 方应用程序中使用的 API - 如果您决定在未来发布它。

于 2012-12-30T22:51:23.290 回答
0

只需做一些简单的事情，通过 HTTPS 在自定义标头中发送授权代码/密码。

于 2012-12-31T08:30:29.890 回答
0

由于 Play Framework 使用 Java，您可以使用Apache Shiro

我还没有使用它..（我打算虽然）所以我不知道它是否是最好的选择。

于 2012-12-30T22:59:18.737 回答
0

那么基本身份验证方法的唯一问题是用户必须每天登录？为什么不为用户提供在设备上保存用户名/密码的选项？这样他就可以在安全性和便利性之间做出选择。

于 2012-12-31T09:52:38.510 回答