使用 MVC 为 iPhone 应用程序构建 RESTful API - 如何保护它？
我将为第三方供应商构建的 iPhone 应用程序编写服务。
我将使用 ASP.NET MVC 来接受帖子并返回 JSON 格式的数据。
我的问题是，你如何保护它？
也许只是使用 API 密钥？这是否足以确保只允许来自 iPhone 应用程序的数据访问指定的服务？
I'm going to be writing the services for an iPhone app being built by a third party vendor.
I'll be using ASP.NET MVC to accept posts and also return JSON formatted data.
My question is, how do you secure it?
Just using an API key perhaps? Would that be enough to ensure that only data from the iPhone apps are allowed to hit the specified services?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我自己也在为同样的概念而苦苦挣扎。我认为第一件事是只使用 HTTPS，这样一开始就比不使用 HTTPS 更安全。
接下来，这取决于您将如何进行身份验证。如果您需要的只是一个 API 密钥（用于跟踪哪个实体正在访问数据），那应该没问题。如果您还想跟踪用户信息，则需要某种方法来关联特定的 API 密钥，该密钥可以基于某处的联接来访问特定类型的记录。
我正在考虑在我的应用程序上进行表单身份验证，并使用身份验证 cookie。幸运的是，IIS 上的 ASP.NET 可以为您完成许多繁重的工作。
示例时间：（我确信我需要添加更多内容，但是当我在工作时，它会提供一些值得咀嚼的内容）
表单身份验证：
在表单正文中发送一对（或多个）字段。这是彻头彻尾的 POST。没有任何不可逆的哈希可以保证这一点的安全。为了确保其安全，您必须始终位于防火墙后面以防止所有入侵者（是的，是的）或者您必须通过 HTTPS。够简单的。
基本身份验证：
通过线路发送“用户名：密码”的 Base64 编码字符串作为标头的一部分。请注意，base64 的安全性就像屏蔽门对于潜艇的安全性一样。您不希望它不安全。需要 HTTPS。
API 密钥：
这表示应用程序应该是 XYZ。这应该是私人的。这与用户无关。优选地，在请求API密钥时，与API授予者共享公钥，允许API密钥在传输时被编码，从而确保其保持私密性但仍然证明源是谁。这可能会变得复杂，但因为有一个应用程序流程并且供应商不会更改它，所以这可以通过 HTTP 完成。这并不意味着每个用户，而是每个使用您的API的开发公司。
因此，您希望发生的是，对于访问您的数据的应用程序，您希望确保它是授权的应用程序，您可以使用私钥进行协商以在运行时进行签名。这可确保您正在与您想要交谈的应用程序交谈。但请记住，这并不意味着用户就是他们所说的那样。
然而。
您可以使用 API 密钥和关联的公钥/私钥对用户名和密码信息进行编码，以便使用 HTTP 通过网络发送它们。这与 HTTPS 的工作原理非常相似，但您只加密消息的敏感部分。
但为了让用户跟踪他们的信息，您必须根据用户的登录情况分配一个令牌。因此，让他们登录，使用适当的系统通过网络发送数据，然后将代表用户的一些唯一标识符返回给应用程序。然后让应用程序在您每次执行用户特定任务时发送该信息。 （通常是所有时间）。
通过线路发送它的方式是告诉客户端设置一个 cookie，我见过的所有 httpClient 实现都知道，当它们向服务器发出请求时，它们会发回服务器曾经设置过的所有 cookie仍然有效。它只会发生在你身上。因此，您在服务器上的响应中设置了一个 cookie，其中包含与客户端通信所需的任何信息。
HTH，请向我提出更多问题，以便我们进一步完善这一点。
I'm sort of struggling with the same concepts myself. I think the first thing is to do HTTPS only, so that it's starting out more secure than not.
Next, it depends on how you're going to do authentication. If all you need is an API key, (to track which entity is accessing the data) that should be fine. If you also want to track user information, you'll need some way to associate that specific API keys can access specific types of records, based on a join somewhere.
I'm looking at doing forms auth on my app, and using an auth cookie. Fortunately ASP.NET on IIS can do a lot of that heavy lifting for you.
Example time: (I'm sure I'll need to add more to this, but while I'm at work it gives something to gnaw on)
Forms auth:
Send a pair (or more) of fields in a form body. This is POST through and through. There's no amount of non-reversible hashing that can make this secure. To secure it you must either always be behind a firewall from all intruding eyes (yeah right) or you must be over HTTPS. Simple enough.
Basic auth:
Send a base64 encoded string of "username:password" over the wire as part of the header. Note that base64 is to secure as a screen door is to a submarine. You do not want it to be unsecured. HTTPS is required.
API key:
This says that an app is supposedly XYZ. This should be private. This has nothing to do with users. Preferably is that at the time that the API key is requested, a public key is shared with the API grantor, allowing the API key to be encoded on transit, thus ensuring that it stays private but still proves the source as who they are. This can get complicated, but because there is an application process and because it won't change from the vendor, this can be done over HTTP. This does not mean per-user, this means per-developing-company-that-uses-your-api.
So what you want to have happen is that for the app accessing your data, that you want to make sure it's an authorized app, you can do negotiation using private keys for signing at runtime. This ensures that you're talking to the app you want to talk to. But remember, this does not mean that the user is who they say they are.
HOWEVER.
What you can do is you can use the API key and the associated public/private keys to encode the username and password information for sending them over the wire using HTTP. This is very similar to how HTTPS works but you're only encrypting the sensitive part of the message.
But to let a user track their information, you're going to have to assign a token based on login based on a user. So let them login, send the data over the wire using the appropriate system, then return some unique identifier that represents the user back to the app. Let the app then send that information every time that you are doing user specific tasks. (generally all the time).
The way you send it over the wire is you tell the client to set a cookie, and all the httpClient implementations I've ever seen know that when they make a request to the server, they send back all cookies the server has ever set that are still valid. It just happens for you. So you set a cookie on your response on the server that contains whatever information you need to communicate with the client by.
HTH, ask me more questions so we can refine this further.
一种选择是使用表单身份验证并使用身份验证 cookie。另外，请确保所有服务调用都通过 SSL 发送。
One option would be to use forms authentication and use the authentication cookie. Also, make sure all the service calls are being sent over SSL.