我有一个应用程序(App1)，它将使用 openURL 方法(例如 App2://[secureToken])使用安全 token 打开另一个应用程序(App2)。 App1 和 App2 位于单独的开发人员帐户上，因此使用权利和钥匙串(keychain)访问组不是这里数据共享的选项，我通常会这样做。
任何应用程序都可以根据 Apple 文档注册任何 url 方案。 iOS 会随机选择要打开的应用程序。因此存在恶意软件注册 App2://的风险。 App1 将使用安全 token 而不是 App2 打开该恶意软件。
我需要一种方法来确保只有 App2 可以在后端服务上使用安全 token 。我可以访问客户端和后端源代码。
我曾想过使用硬编码的 key 分发 App2，并将其添加到钥匙串(keychain)并使用该信息生成某种散列。但考虑到安全 token 包含高度关键的信息，我认为硬编码 key 对于这种情况还不够强大。 (硬编码的 key 很容易被泄露，见 https://security.stackexchange.com/questions/52584/why-can-we-still-crack-snapchat-photos-in-12-lines-of-ruby)
有没有办法在后端验证 App2 的开发者账号？我更喜欢将此作为解决方案，但也欢迎任何替代方案。
最佳答案
我发现最接近这个的是收据。 (免费应用程序也有收据)问题是收据中没有识别唯一设备，所以它仍然是欺骗性的。有一些有用的信息，例如用于欺诈检测的原始购买日期，但它本身并不是很有用。
(https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html#//apple_ref/doc/uid/TP40010573-CH106-SW1)
Facebook 将此漏洞列为“窃取 URL 方案”(https://www.facebook.com/notes/facebook-security/securely-developing-on-mobile/10151408888270766)
并推荐
“为了减轻对调用者 URL 方案的欺骗，Facebook SDK 还允许主应用程序的调用者选择一个加密 key 来响应。”
为了避免硬编码加密 key ，我想我会做这样的事情。
如果 App2 之前没有进行身份验证，App1 将不会创建安全 token 。当 App2 第一次进行身份验证时，将在服务器端生成一个 key 并传递给 App2。它将存储在钥匙串(keychain)中。
下次 App1 调用 App2 时，App1 将从服务器查询该 key 并使用此信息加密安全 token 。
关于ios - 在后端验证 ios 开发者帐户，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22265754/