4

我在网络上收到了关于首选 REST API 身份验证/授权机制的混合信号，尤其是对于移动应用程序。

  1. 有 OAuth 1.0，但它声称比它需要的更复杂，并且不能很好地支持本机客户端（回调 URL 非常以浏览器为中心）。另一方面，有一个支持它的主要提供商（Twitter）。
  2. 然后是 OAuth 2.0，它应该是对 1.0 的改进，它在默认咒语中摆脱了客户端加密（替换为不记名令牌），但有些人认为它被设计破坏了，并且不记名令牌并不比 cookie 好。来自粗略提供商的 SSL 证书可以更容易地欺骗移动客户端，使其相信端点是受信任的权威机构。然而，两个主要的供应商（谷歌和 Facebook）支持它。
  3. 还有一些人，他们主张回避整个混乱并自己动手。

那么它是哪一个？

4

2 回答 2

3

这听起来像是对冲，但答案是“任何适合您的应用程序”。

像 OAuth 和 OpenID 这样的 3rd 方身份验证系统占有一席之地，它们非常适合某些应用程序，尤其是那些允许客户端成为 API 用户而无需将其个人凭据分叉到另一个服务器系统的系统。

但是，您可能正在构建一个没有该约束或要求的系统，并且要求您的客户简单地在您的服务器上创建一个帐户可能是合理的。在这种情况下，您可能可以通过使用 HTTPS 和 Basic Auth 大大简化事情。让客户端在适当的标头中传递他们的用户名/密码，并确保您的连接受 SSL 保护。或者，让客户为其凭据使用证书。

我建议您首先列举“安全”对您意味着什么，然后从头开始工作。考虑每个相关方面，例如完整性保证、不可否认性、重放保护、客户端影响、性能和 API 可用性。从那里，确定您是否只需要 HTTPS/基本身份验证，或者您是否还需要添加 API 密钥、OAuth、OpenID、校验和等。

于 2012-04-26T15:25:38.513 回答
1

我会推荐 OAuth 2，但会在客户端进行额外的证书检查。如果您的证书来自 Verisign，则使来自其他 CA 的所有证书无效。确保始终在同一个 CA 获得证书，除非您喜欢分发更新。

然而，最后，只有客户端才能验证与服务器的连接是完全安全的。永远别忘了。

于 2012-04-26T15:37:13.683 回答