问题描述
我们正在构建一个移动应用，并希望实施某种身份验证，以确保 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 来识别您的用户，因为对它的访问已被弃用.您可以通过在安装应用程序时在设备上创建自定义设备 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.
这篇关于如何确保 API 请求来自我们的移动 (ios/android) 应用程序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！