如何确保API请求来自我们的移动(ios/android)应用?
我们正在构建一个移动应用程序，并希望实现某种身份验证，以确保仅我们的应用程序可以访问该API.该应用程序的用户是匿名用户，没有登录名，尽管我确实通过设备ID来识别他们以维护设置等.
We're building a mobile app and want to implement some kind of authentication to make sure the API is only being accessed by our app. The users of the app are anonymous, with no logins, though I do identify them through the device id for maintaining settings and such.
最简单的方法似乎是生成一个Guid/API密钥，该密钥与SSL上的每个请求一起发送.
The easiest approach seems to be generating a Guid / API Key that I send with every request over SSL.
让我担心的是，拥有大量空闲时间的恶意软件可能会下载该应用程序，对其进行反编译以获取API密钥和JSON请求，然后尽可能地破坏我的数据库.
What worries me is the possibility that a malicious person with a lot of free time would download the app, decompile it to get the API Key and the JSON requests, and then trash my database as best they can.
SSL，API密钥，设备ID和具有尽可能受限制的调用的API是否足够好?我应该采取其他方法吗?我的恐惧是有根据的还是毫无根据的?
Is SSL, an API Key, a Device ID, and an API with as-constrained-as-possible calls good enough? Should I be taking a different approach? Are my fears founded or baseless?
请勿在应用程序中嵌入单个API密钥.您的担心对于恶意用户的影响是有效的.另外，您在当前设置中存在一个严重漏洞，您可能会让恶意API用户通过提供伪造的UDID来更改其他用户的首选项.
Do NOT embed a single API key in the app. Your concerns are valid regarding the effect of malicious users. Also, you have a serious vulnerability in your current setup where you could have a malicious API user change other user's preferences by providing fake UDIDs.
相反，在设备上首次启动应用程序时创建一个注册"服务，该服务会基于UDID生成并返回GUID.将GUID存储在设备本地用户首选项和服务器上.跟踪GUID，并根据服务器上的每个请求将其与UDID匹配.
Instead, create a "registration" service that is called upon first time app startup on the device which generates and returns a GUID based on the UDID. Store the GUID in your device local user preferences and on the server. Keep track of the GUID and match it up with the UDID on every request on your server.
确保所有这些操作均通过SSL进行.
Make sure all of this occurs over SSL.
使用这种方法，不会滥用任何嵌入式主API密钥.另外，您可以通过标记GUID/UDID组合将滥用用户列入黑名单，还可以消除现有的可能对现有注册设备进行伪装的问题.但是，您不能防止恶意注册尚未在您的服务中注册的设备.使用设备ID作为用户标识符永远都是潜在的危险.
With this approach there is no embedded master API key to be abused. Also, you can blacklist abusive users by flagging GUID/UDID combinations and you can also eliminate your existing issue of potential masquerading of existing registered devices. However, you cannot prevent malicious registering of devices that have not already registered with your service. That will always be a potential hazard of using a device id as a user identifier.
甚至有更好，更完善的身份验证机制，它们采用了更好的方法，即您应该查看的OAuth，JSessionID等.
There are even better and more established authentication mechanisms that take a better approach, ie. OAuth, JSessionIDs, etc. that you should take a look at.
此外，由于不建议使用UDID，因此将来不应该使用UDID来标识您的用户.您可以通过在安装应用程序时在设备上创建自定义设备GUID并将其保存在本地用户首选项中来模仿UDID，以实现您的目的.
Also, in the future you should not be using the UDID to identify your users since access to it has been deprecated. You can mimick the UDID for your purposes by creating a custom device GUID on the device upon application installation and saving it in your local user preferences.