Geek Answers Handbook

Facebook login programmatically using OAuth / XAuth (?)

I am making an application that should be able to share stories with Facebook using a password and email address that were set somewhere programmatically (not using Facebook-Connect, mainly because I want my own design, regardless of Twitter or Facebook from the app).

I have already done this with Twitter and XAuth, and it works brilliantly. Is there a way I can achieve the same with Facebook, or just plain OAuth? (Or Facebook supports XAuth, will that make it a lot easier?)
Is there any other way to achieve what I want?

+4
source share
4 answers

The theory is that your application should never see the user's password.

In practice, since all the code runs in your application, it is trivial to get the user password (and it’s about as simple as imagining a similar user interface to grab the user password).

Since you have the full source code, just calling a function that logs in with a username and password is enough. I do not recommend this:

  • Facebook probably won't like it, and may cancel your application API API.
  • You should not store usernames / passwords unless you absolutely need it, especially in NSUserDefaults (which are used by Settings.app), since it is completely unencrypted.
  • Setting.app does not support password fields.
  • The user does not need to leave the application, go to "Settings", add login information and return to your application. This is slightly better with multitasking, but not much better.

What happened using a regular Facebook login screen?

EDIT: Read more ...

  • AFAIK, you cannot encrypt NSUserDefaults reliably as it was saved in Settings.app. You cannot decide which file it is written to (Library / Preferences / com.example.myapp.plist, I think). In iOS 4, you can set NSFileProtectionKey = NSFileProtectionComplete, but this has a bunch of problems:
    • You install this in your application. The user can go to Settings.app before launching the application.
    • While you can presumably include Library / Preferences / com.example.myapp.plist in your zip / ipa application, I don't think you can include the NSFileProtectionKey attribute.
    • NSUserDefaults updates the plist atomically, writing the new plist to a new file and renaming the file over the old one. The new file is unlikely to have NSFileProtectionKey = NSFileProtectionComplete.
    • Ultimately, if you pass control over the data to an API that gives no security guarantees, it is unsafe (NSUserDefaults seems apt to leave a lot of temporary files lying around ...). Apple provided a keychain specifically for storing passwords (there’s even some decent example code there!); use it.
  • Apple does not recommend using Settings.bundle, as well as its own settings screen - you must choose one or the other.
+5
source

For sites using OAuth, such as Facebook, what you are trying to do is bypass user security. For a simple description of OAuth, check out this link: http://bit.ly/awynlU The short option is that Facebook is responsible for authenticating the user and does this on their servers. As already mentioned, the theory is that you never see the password.

Good, bad or indifferent, it is assumed that you want to prevent. If this can be done, this is in violation of the security model that the site has installed - Facebook in this case.

By the way, Twitter is also moving towards OAuth. According to the information I have, "starting on August 31, all applications will need to use" OAuth "to access your Twitter account."

+2
source

I wonder why you really want to go with such a hacker approach. The user only needs to log in once to receive the OAuth2 token, and from there you can send as many times as you want Facebook, do not even ask the user to log in with Facebook.

+1
source

You should be able to use the new facebook SDK to implement facebook single sign-on. Thus, if the user already has the facebook application installed on their device, they are already logged in, and this is a much better experience than the old popup popup implementation. For your application, you must provide access to your account, but besides that the ugly sign screen is not used.

If they do not have the facebook application installed, it will launch in the browser.

Both methods use URL processing to return to your application after authentication.

Read more about this here: http://developers.facebook.com/docs/mobile/ios/build/#implementsso

In terms of implementing your own login screen instead, it is against Facebook TOS, because they want a consistent and familiar sign in the platform to avoid common problems with phishing, etc. To a large extent, they insist on educating their users only to provide their usernames and passwords to legitimate pages.

+1
source

More articles:


All Articles