这可能是一个通用的安全问题，但我想我会问我正在开发什么。
场景是：一个Web服务（WCF Web Api），它使用API Key来验证并告诉我用户是谁，以及前端的jQuery和应用程序的混合。
一方面，流量可以是https，因此无法检查，但如果我每个用户使用相同的密钥（比如一个guid），并且我在两者中都使用它，那么就有可能采取这种方式，有人可以冒充用户。
如果我实现类似于OAuth的东西，那么会生成一个用户和每个应用程序密钥，这可能会起作用 - 但是对于jQuery方面，我还需要javascript中的应用程序API密钥。
如果有人在实际计算机上并且执行了视图源，那么这只会是一个问题。
我该怎么办？
我确定这可能是一个常见的问题 - 所以任何指针都会受到欢迎。
为了让这个更清晰 - 这是我写的API，我写的是我要查询，而不是谷歌等。所以我可以做每个会话令牌等，我只是想找出保护我将使用的客户端令牌/密钥的最佳方法。
我在这里有点过于谨慎，但只是用它来学习。
答案 0 :(得分：18)
（我建议将这篇文章标记为“安全”。）
首先，你应该清楚你正在保护什么。你能信任客户吗？一个狡猾的用户可以在您的页面上粘贴Greasemonkey脚本，并准确调用您的UI调用发送请求的代码。将所有内容隐藏在Javascript闭包中只意味着您需要一个调试器;它不会使攻击变得不可能。 Firebug可以跟踪HTTPS请求。还要考虑受感染的客户端：是否安装了键盘记录器？整个系统是否秘密运行虚拟化，以便攻击者可以随时随地检查内存的任何部分？当你像webapp一样暴露时的安全性真的很棘手。
尽管如此，您可以考虑以下几点：
考虑不使用密钥，而是使用HMAC哈希值，例如，您在认证时立即提供的令牌。
DOM存储可能比使用cookie更难捅。
查看Google's implementation of OAuth 2示例安全模型。基本上，您使用的令牌仅在有限时间内有效（并且可能对于单个IP地址有效）。这样即使令牌被拦截或克隆，它也仅在很短的时间内有效。当然，当令牌用完时你需要小心你做的事情;攻击者是否可以像你的代码那样做同样的事情并获得一个新的有效令牌？
不要忽视服务器端安全性：即使您的客户端在提交请求之前已经检查过，如果用户实际上有权执行他们要求的操作，请再次检查服务器。事实上，这个建议可以避免上述大部分内容。
答案 1 :(得分：7)
这取决于API密钥的使用方式。 Google提供的API密钥与发起请求的网站的网址相关联;如果您尝试在具有备用URL的站点上使用该密钥，则该服务将引发错误，从而无需保护客户端上的密钥。
然而，一些基本API与客户端绑定，可以跨多个域使用，因此在此实例中，我之前已经将这个API包装在服务器端代码中，并对客户端如何与之通信进行了一些限制。本地服务和保护服务。
然而，我的总体建议是对Web API应用如何使用密钥的限制，从而消除了在客户端尝试保护密钥的复杂性和必要性。
答案 2 :(得分：2)
通常在这种情况下，虽然您通过服务器使用'AJAX'代理请求，该'AJAX'验证浏览器是否有权这样做。如果您想直接从JavaScript调用服务，那么您需要某种令牌系统，如JSON Web Tokens (JWT)，如果服务位于当前域以外的某个位置，则必须解决跨域问题。< / p>
答案 3 :(得分：2)
如何使用jQuery调用处理与API通信的服务器端代码。如果您正在使用MVC，则可以调用控制器操作，该操作可以包含代码和API密钥以命中您的服务并返回部分视图（甚至是JSON）到您的UX。如果您使用Web表单，则可以创建一个aspx页面，该页面将在后面的代码中进行API通信，然后将内容写入响应流以供您使用。然后，您的UX代码可以包含对服务器端代码的一些$ .post（）或$ .load（）调用，并且您的API密钥和端点都将受到保护。
答案 4 :(得分：0)
有关详细信息，请参阅http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx （如何在.NET 4中对REST服务进行API密钥验证）