反向OTP流有哪些缺点，其中OTP在网站上可见，并且在经过身份验证的移动客户端上重新键入？

Question

我想对第三方网站上的用户进行身份验证(这或多或少是一个OAuth流，因此该网站将能够在事后代表我的用户执行操作，例如接收她的一些数据)。我的用户已经在我的移动应用程序中进行了认证。

现在，多个网站实现OTP时，我输入在移动设备上生成的代码(SMS消息、身份验证程序或任何本地应用程序)。

我想扭转这个流程，即在网站上生成一个OTP，并允许用户将其输入到移动应用程序中，在该应用程序中，他已经通过了身份验证。

在第三方网站上，可能会打开一个新的子窗口，通过API直接从我的服务器下载OTP。

问:这种流动有什么坏处吗？

PS我看到了以下优势:在正常的流程中，一个假冒的第三方网站会“窃取”我的OTP。在我的流程中，即使他们能够看到OTP，实际的匹配也只有在经过身份验证的环境中输入代码之后才能执行。在用户输入OTP之前，它甚至不与用户关联！

Answer 1

这些方法在技术上和彼此一样安全。

然而，有几个实际的注意事项：

• 这两种设备现在都必须有internet，而不仅仅是登录的设备。
• 用户可能接受过不共享代码的培训，但可以直接输入代码。
• 将需要一个自定义应用程序或某种方式接收来自用户的短消息。

Answer 2

你的“优势”是错误的，这并不能使你更加安全。攻击者不会试图欺骗用户将经过身份验证的应用程序中的OTP输入到钓鱼页面，而是试图欺骗用户将OTP从网络钓鱼页面输入到经过验证的应用程序中。