2

我正在基于 Play Framework 2.X 为我的项目构建一些 RESTful API。

我的重点是我实现的身份验证机制。

目前，我使用SecureSocial。工作流程是：

  1. 匿名用户调用安全 API
  2. 服务器抓取任何 cookie Id（一种身份验证令牌）并检查 Play 2 缓存中的匹配。（缓存包含 cookie Id（随机生成）和用户 Id 之间的关联，可从数据库访问。
  3. 如果有任何匹配，则授权用户处理其预期的服务。
  4. 如果没有匹配，用户被重定向到登录页面，当填写有效凭据（电子邮件/密码）时，服务器将其相应的身份验证数据存储在 Play 2 缓存中，并发送仅包含自定义 Id（身份验证令牌）的新创建的 Cookie给用户，当然，通过 SSL 保护。
  5. 虽然 cookie/token 不会过期，但用户可以调用安全 api（当然，如果授权）

整个作品很棒。

但是，经过一番搜索，我发现了这篇文章，并且......我想知道我是否走对了。

事实上，处理 cookie（Play 术语中的“会话”）会打破 Restfulness 规则。因为一个真正被认为是无状态的 api 应该一次调用所有需要的数据（凭证/令牌等）。我实现的解决方案需要两个调用：一个进行身份验证，另一个调用安全 API。

我想把事情做好，我想知道一些事情：

  • Api 密钥的使用情况如何？我应该使用它们而不是这个SecureSocial工作流程来实施解决方案吗？Api Keys 将在每次 API 调用时发送，以保持安静。我考虑了一下，因为我希望我的 API 可以被一些 web 应用程序、手机和其他类型的客户端访问。没有人被迫管理cookies。

  • OAuth 呢？我真的需要它吗？它会完全取代简单 api 密钥的使用吗？始终以多个客户端为目标，此已知协议将是管理身份验证和授权的好方法。

总之，我应该实施另一种机制以符合 Restful 标准吗？

4

1 回答 1

1

这是一个相当老的问题，但仍然值得回答，因为它可能会引起其他人的兴趣。REST 确实要求无状态，但在实施时授权是一个常见的例外。您描述的解决方案需要一个授权过程，然后是基于授权 cookie 的大量服务调用。这类似于 api 密钥或 OAuth。只要服务不具有高安全性并且您在合理的时间后过期，cookie 就没有任何问题。将 OAuth 集成到您的服务中听起来有点矫枉过正，仅当您将 API 公开给第三方（组织外部）时才建议这样做。

于 2014-03-12T06:44:33.750 回答