场景：
一个 Web 应用程序，一旦新用户完成注册，就会发送一封电子邮件，其中包含一个 URL，一旦从 iOS 设备中点击该 URL，就会启动 iOS 应用程序。该场景是让用户使用移动应用的经典场景。
在实现它（使用 URL 方案）时，我们开始想知道这种方法的安全性如何？从理论上讲 - 恶意应用程序可以注册相同的 URL 方案，根据 Apple 的说法：
注意：如果多个第三方应用程序注册处理相同的 URL 方案，目前没有确定哪个应用程序将获得该方案的过程。
在这种情况下，如果用户点击电子邮件中的 url，则不知道将启动两个（或多个应用程序）中的哪一个 - 我们的应用程序或恶意应用程序。假设正在启动一个不同的应用程序 - 如果它真的是恶意的，理论上它可以模仿我们应用程序的登录页面并获取用户的凭据。
是否有处理这种情况的最佳实践？我已经阅读了很多关于这个问题的文章，他们都声称唯一的解决方案是等待 Apple 使这些 url 方案独一无二。 示例 1 , 示例 2
如果存在该问题的任何解决方案，我很乐意听到，在此先感谢！
我们必须假设恶意应用程序可以拦截此 url 中包含的任何数据，并且它的作者可以自由地对您的应用程序中包含的任何行为进行逆向工程，以便它可以模仿您的 UI 和您的应用程序尝试执行的任何验证。但是，我们也可以假设恶意应用程序包含在其自己的沙箱中，因此您的应用程序可以与您的后端私下通信。恶意应用程序可以模仿任何此类通信，但这确实允许我们构建恶意应用程序未知的秘密。这至少让我们有机会设计一些对策。
一种选择可能是：
现在我们已向您的应用发送数据，这些数据可能会被重定向到恶意应用，但恶意应用无法读取。这是部分解决方案。我们仍然需要小心设计一个不鼓励用户陷入网络钓鱼攻击的 UI，因为 URL 可能仍会启动冒名顶替者。
编码数据可能是我们可以用来对用户进行身份验证的令牌，因此从不要求他们在应用程序中重新进行身份验证。然后没有可以模仿的登录屏幕（尽管巧妙的伪造可能仍然足以欺骗用户泄露他们的凭据）。
另一种方法可能是使用存储在客户端上的类似的每用户机密作为盐与用户的密码组合。仅他们的密码可能不足以进行身份验证，因此捕获其凭据的恶意应用程序无法立即访问他们的帐户。
另一种设计可能是允许用户以可识别的方式定制他们的体验。您可以在登录屏幕上显示他们选择的个人资料图像。如果只有您的应用知道该选择，那么模仿者不应该能够可靠地复制它（同样，不能保证这意味着用户会被欺骗）。
所有这些都引入了权衡；用户仍然可能被诱骗向恶意应用程序泄露信息，无论它们与您的合法客户端有多么不同，客户端机密可以被其他攻击提取，并且您需要一个计划来支持切换、丢失或升级设备的用户。您必须决定其中任何一项是否真正提高了用户的安全性，以及是否值得为此付出代价。
尝试这样的事情：
在您的电子邮件中，声明单击 URL 将启动应用程序并首次登录，然后提示用户输入新密码。在 URL 中包含一个令牌，当您的应用程序处理该令牌时，它会进行一次性登录并将用户置于“新密码”页面上。
如果恶意应用程序还注册了您的自定义 URL 并窃取了链接，那么他们应该（希望）无法对它做太多事情。即使他们复制了您的界面并提示用户输入新密码，也不会产生任何效果。
编辑：在进一步考虑之后，只要你有一个积极的攻击者，你就完蛋了。攻击者可以继续模拟您的应用程序，有效地对您进行 MITM，无论您做什么，只要他们能够劫持该初始 URL。我的解决方案只适用于最基本的情况，并不可靠。