我有一个应用程序（App1），它将使用openURL方法（例如App2：// [secureToken]）打开另一个带有安全令牌的应用程序（App2）。 App1和App2属于单独的开发者帐户，因此使用权利和＆amp;钥匙串访问组不是这里的数据共享选项，我通常会这样做。
任何应用都可以根据Apple文档注册任何网址方案。 iOS会随机选择要打开的应用程序。因此，恶意软件可能会注册App2：//。 App1将使用安全令牌而不是App2打开该恶意软件。
我需要一种方法来确保安全令牌只能由后端服务上的App2使用。我可以访问客户端和后端源代码。
我想过用硬编码密钥分发App2并将其添加到keychain并使用该信息生成某种哈希。但我认为，考虑到安全令牌包含非常关键的信息，硬编码密钥对于这种情况来说还不够强大。 （硬编码密钥很容易受到损害，请参阅https://security.stackexchange.com/questions/52584/why-can-we-still-crack-snapchat-photos-in-12-lines-of-ruby）
有没有办法在后端验证App2的开发者帐户？我希望这是一个解决方案，但也欢迎任何替代方案。
答案 0 :(得分：0)
我发现最接近的是收据。 （免费应用程序也有收据）问题是没有什么可以识别收据中的唯一设备，所以它仍然是可欺骗的。有一些有用的信息，如欺诈检测的原始购买日期，但它本身并不是很有用。
Facebook将此漏洞列为“盗取网址方案”（https://www.facebook.com/notes/facebook-security/securely-developing-on-mobile/10151408888270766）
并建议
“为了减少对来电者的URL方案的欺骗，Facebook SDK还允许主应用的呼叫者为他们的响应选择加密密钥。”
为了避免硬编码加密密钥，我想我会做这样的事情。
如果App2之前未进行身份验证，App1将不会创建安全令牌。当App2首次进行身份验证时，将在服务器端生成密钥并将其传送到App2。它将存储在钥匙串中。
下次App1调用App2时，App1将从服务器查询该密钥并使用此信息来加密安全令牌。