security - REST API 安全性的当前状态是什么？

Question

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

有 OAuth 1.0，但据称它比它需要的更复杂，并且不能很好地支持 native 客户端(回调 URL 非常以浏览器为中心)。另一方面，有一个主要的提供商支持它(Twitter)。

然后是OAuth 2.0，它应该是对1.0的改进，它在默认咒语中摆脱了客户端加密(用不记名 token 代替)，但有些人认为it's broken by design , 和 bearer tokens are no better than cookies .来自粗略提供商的 SSL 证书可以更容易地诱使移动客户端相信端点是受信任的机构。然而，两个主要提供商(谷歌和 Facebook)支持它。

然后还有人，他们advocate sidestepping the whole mess and rolling your own.

那么它是哪个？

Answer 1

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

OAuth 和 OpenID 等 3rd 方身份验证系统有其一席之地，它们非常适合某些应用程序，特别是对于允许客户端成为 API 用户而无需将其个人凭据 fork 到另一个服务器系统的系统类型。

但是，您可能正在构建一个没有这种限制或要求的系统，要求您的客户在您的服务器上简单地创建一个帐户可能是合理的。在这种情况下，您可能可以通过使用 HTTPS 和基本身份验证显着简化事情。让客户端在适当的 header 中传递他们的用户名/密码，并确保您的连接受 SSL 保护。或者，让客户端使用证书作为其凭据。

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