我正在开发一个本机 iOS 应用程序，该应用程序利用了我的后端服务器提供的一些 Web 服务。有些服务需要对用户进行身份验证，要求是通过直接在服务器上创建的用户帐户（使用 Facebook 或 Twitter）执行身份验证。
为了简化事情，后端服务器的创建者决定服务器将使用 FB 或 Twitter 进行服务器端身份验证（或者如果用户选择直接使用帐户登录，当然使用自己的身份验证机制）服务器），并在身份验证成功后返回我自己的服务器访问令牌，独立于它遵循的流（FB / Twitter /自己）。
因此，当前的身份验证流程如下所示：
- 我使用登录页面的 URL 从本机 iOS 应用程序打开一个 Web 视图。该页面有一个“使用 FB 登录”和一个“使用 Twitter 登录”按钮，以及一个用于直接验证的小型用户/通行证表单。
- 如果用户选择“使用 FB 登录”，服务器会将 Web 视图重定向到 FB 应用程序的身份验证页面，用户应在其中输入其 FB 凭据。Twitter也发生了同样的事情。
- FB/Twitter 重定向 URL 直接设置到服务器，因此 FB/Twitter 成功验证用户后，它会将访问令牌发送到服务器。服务器创建一个新的用户会话，生成自己的访问令牌并将其发送到本机应用程序的重定向 URL。
- 如果用户在表单上输入直接服务器凭据，则服务器简单地创建用户会话、其身份验证令牌并将其发送到重定向 URL。
- 原生应用程序通过其委托观察 Web 视图，并不断寻找预定义的重定向 URL（类似于
http://myserver.com/authentication_success/?authToken=xyz）。如果传入的请求shouldStartLoadWithRequest与此模式匹配，它会提取 authToken 并关闭 Web 视图。 - 身份验证令牌将传递给需要用户身份验证的每个服务请求。
我的问题是：这种架构是否有效并且会被 Apple 接受？我担心的是，由于在某个时候可能会要求用户在我的网络视图中输入其 Facebook 凭据，理论上我可以通过代理访问他的 FB 密码。这可能是拒绝该应用程序的理由吗？
我找到了这个文档：https ://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/谈到您可能希望使用基于浏览器的登录来进行“登录使用完全服务器端代码的流程”。我的案子可以适用于这个案子吗？