I am developing a native iOS app that leverages some web services provided by my backend server. Some services need the authentication of the user and the requirements are that the authentication would be carried out either by a user account created directly on the server, either with Facebook, or with Twitter.
To simplify the things, the creators of the backend server have decided that the server would carry out server-side authentication with FB or Twitter (or of course use its own authentication mechanism if the user chooses to log in with directly with the account on the server), and return me an own access token of the server after the authentication succeeded, independently from which flow (FB/Twitter/own) it followed.
So the current flow of authentication looks like:
http://myserver.com/authentication_success/?authToken=xyz
) If the request passed in shouldStartLoadWithRequest
matches this pattern, it extracts the authToken and closes the web view.My question is: is this architecture valid and will be accepted by Apple? My concern is that since at a certain point the user might be asked to enter its Facebook credentials on my web view, theoretically I could access his FB password through the delegate. Could it be a reason to reject the app?
I found this doc: https://developers.facebook.com/docs/facebook-login/login-flow-for-web-no-jssdk/ that speaks about that you might want to use browser-based login for a "login flow using entirely server-side code". Can my case applied to this case?
A follow up to this question: I submitted to the App Store an app with the fb-login architecture outlined above and it was accepted and published.