Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Facebook Connect for mobile single sign on

Hey all,

I've got an app that currently lives only in Facebook (well, as far as any user interaction goes) which I'm trying to build a Facebook Connect authenticated mobile app for.

As far as I can tell, the Titanium Facebook implementation is good for authenticating directly to Facebook from the device, but not as authentication for talking separately to by web service.

I need to somehow carry an authenticated session across to a separate XHR request which I can then use to share exchange a separate set of credentials which I'll use for future non-Facebook requests. On the web, this would be achieved thorough a cookie that gets set by the Facebook login, used to generate the facebook session on future requests.

I've not had much interaction with Connect mobile (and I'm by no means an expert when it comes to Connect for sites) so for all I know this might not be possible, but it doesn't seem like an unusual use case.

The best I've come up with so far is taking the session key and passing that back up to the server, but that has a whole bunch of reasons not to do that.



— asked June 2nd 2010 by Jon Gilbraith
  • authentication
  • connect
  • facebook
  • single-sign-on

3 Answers

  • Accepted Answer

    SSO with Facebook Connect has been done on a client project, so I do know it to be possible with Titanium Mobile. The information that will be potentially useful for this purpose is in the Ti.Facebook.session property:


    Using this information, your client application can tell that the user is logged in, and for how long. You could leverage this data on the server side to authenticate requests.

    Personal Opinion

    I would advise against using Facebook as your SSO solution - allowing Facebook to own your user accounts puts you at the mercy of their servers and systems to drive your entire back end. My recommendation would be to associate Facebook accounts with user accounts that you control, so you can still leverage social graph and sharing APIs without making your site totally dependent on Facebook.

    — answered June 2nd 2010 by Kevin Whinnery
    1 Comment
    • Thanks Kevin, my concern with using only those details was they could surely be supplied by anyone with access to the user's session info? (i.e. the owner of any other Facebook app they have installed.) Having read up on the session secret though, that seems like what I need to provide that security.

      As for relying on Facebook - entirely with you there! I'm only using Facebook as a way to build my initial user base and as soon as I can I'll start introducing a separate log on.

      I'm still at the "minimise barrier to entry" stage of things :-)

      — commented June 2nd 2010 by Jon Gilbraith
  • I do not believe you can store a cookie but you can store the info in a sqlite database. So when the user login to FB or another site and the response is not an error message, then simply store the username and password in the database. Then when the user needs to access the site again just have the app pull out the username and password and resubmit it with the query.

    — answered June 2nd 2010 by Stan Thompson
  • Hi Stan, thanks for responding.

    I've tried something along those lines using the session key, which is available in Ti.Facebook.session.

    If I pass that to my app, I'm able to recreate the session and take things from there, though I'm not too happy with that as I've not got any way to verify that request has come from who I expect it to be.

    I have however just revisited what else is in Ti.Facebook.session and there's the session secret. I'm not familiar with that but I suspect that's where my answer lies so I'll go RTFM for a bit and report back.



    — answered June 2nd 2010 by Jon Gilbraith
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.