通用的方式来验证客户端并保护RESTful api

Question

我一直在挖掘stackoverflow/security.stackexchange线程,并没有明确的答案为客户提供一种通用的方式来安全地使用我正在通过asp.net的web api构建的RESTful服务.在搜索这个答案时,我看到"授权"和"身份验证"可以互换使用,所以我想指出我只想验证请求身份和合法性.所以,在这一点上,我不是在验证用户.

亚马逊的模型似乎是"滚动你自己"时引用的模型,但是,在这种情况下,我确实理解亚马逊已经提供了每篇论文的"论文",所以这里没有太多的重新发明.这篇文章, 设计一个没有OAuth的安全REST(Web)API,非常有帮助.

我收集的是:

1. 应用程序必须要求SSL请求,因此应拒绝" http://myapi.com/users/1 "上的GET,并提供错误的请求响应,以便开发人员知道需要https.
2. 客户必须提供应用密钥/密钥以验证他们是谁.
3. SSL +证书是个好主意
4. 需要nonce值
5. 当客户注册他们的应用程序时,需要输入URL和IP,他们将在收到请求时发送请求以进行验证.我对此的关注是外部应用程序的可移植性,即应用程序被移动到具有不同IP的新服务器,现在它不起作用.

我对2的问题很少,或许,我的思绪无法绕过.首先,不是应该保密的app秘密吗？那么,如果一个javascript客户端发出请求,这不会影响app密钥的保密性吗？为什么有一个应用秘密然后我可以通过验证应用密钥,现时值和服务器IP验证请求身份？我确实理解像php,ruby或c#.net这样的服务器端语言不会暴露这个秘密,但我希望这对JS和编译语言来说都是普遍安全的.

最后,Facebook有一个开发人员安全检查表告诉开发人员"永远不要在客户端或可编译代码中包含你的App Secret",这会向我建议加密的web.config等.此解决方案不适用于将REST服务暴露给通过javascript消费的任何人.

其他线程我已经通过梳理:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
https://developers.facebook.com/docs/facebook-login/安全性/
保护REST API/Web服务的最佳实践
REST身份验证方案的安全性
HTTP基本身份验证而不是TLS客户端认证
RESTful身份验证

Answer 1

我保护应用程序安全的方式是使用 OpenID Connect。对于您的示例，您在 #2 中讨论的客户端将是 RP（资源提供商），而像 Google 这样的身份验证系统将是您的 OP（OpenID 提供商）

客户端必须提供应用程序密钥/秘密以验证他们的身份。

实际上是您的应用程序，您的客户端密钥不会像您的/etc/passwd文件一样离开您的服务器。RP 使用此秘密与 OP 通信以获取数据。

简而言之，流程是

1. 用户连接到您的 API 端点，例如/restapi
2. 您的端点将用户重定向到您注册应用程序的 Google
3. 用户登录 OP（例如 Google）并获取要传递给 RP 的代码
4. RP将去OP获取openid信息例如电子邮件
5. 然后 RP 将使用该 openid 信息来查找自己的授权表
6. 一旦 RP 验证了用户的授权，RP 将提供其余信息。