我正在开发一个原生iOS应用程序，它利用了后端服务器提供的一些Web服务。某些服务需要对用户进行身份验证，并且要求身份验证将由直接在服务器上创建的用户帐户执行，无论是使用Facebook还是使用Twitter。
为了简化事情，后端服务器的创建者已经决定服务器将使用FB或Twitter进行服务器端身份验证（或者如果用户选择直接使用服务器上的帐户登录，则当然使用自己的身份验证机制），并在身份验证成功后返回我自己的服务器访问令牌， 独立于它遵循的流程（FB/Twitter/own）。
因此，当前的身份验证流程如下所示：
- 我使用登录页面的 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 视图。
身份验证 - 令牌将传递给需要用户身份验证的每个服务请求。
我的问题是：这种架构是否有效，是否会被苹果接受？我担心的是，由于在某个时候可能会要求用户在我的网络视图上输入其Facebook凭据，理论上我可以通过委托访问他的FB密码。这可能是拒绝该应用程序的理由吗？
我找到了这个文档：https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/谈到您可能希望使用基于浏览器的登录来"完全使用服务器端代码的登录流程"。我的案件可以适用于这个案件吗？
这个问题
的后续：我向App Store提交了一款具有上述fb-login架构的应用程序，它被接受并发布了。