2

As we all know social networks like Twitter, Facebook have their own mobile apps. Other 3rd party apps use their API which can be authenticated over only OAuth protocol after registering for an app.

So how exactly do Facebook, Twitter, Foursquare etc. access their API on their own mobile apps via authenticating by "username" and "password"? I don't think that they just send username and password as parameter on each request.

One more important point is, when you log in those official mobile apps, you don't come across a web interface, asking for permission and has button "Allow this app" which exists in OAuth process. They're authenticated by default!

While investigating I came across XAuth, however after watching its introductory video, it seemed like a shared storage on browser. I'm not looking for that and then I came across use of xAuth in Twitter. It authenticates by sending username/password once over SSL and then server issues an OAuth token/secret pair. (This looks like OAuth v1 instead of v2, which is not cool.)

It looks like what I'm looking for but I'm not quite sure. Are there any alternatives other than maintaining an OAuth server that xAuth requires? Because in my use case, probably 3rd party apps will not exist at all.

ahmet alp balkan
  • 42,679
  • 38
  • 138
  • 214
  • 1
    This is a common problem. A good introduction is here : http://stackoverflow.com/questions/1634425/api-authentication-design-and-hackability – Burak SARICA Oct 31 '11 at 18:58

1 Answers1

2

In cases like these, the official apps just use whatever authentication they want. I think the point of using OAuth and XAuth for non-official applications are to allow some access to those 3rd parties that (1) can be revoked by the user, and (2) don't require the 3rd party to have the username/password of the user themselves. In fact, before more widespread adoption of OAuth, et al., 3rd party apps requiring your username and password were very common. It was only after Facebook turned off this kind of access, that the OAuth method became more commonly used (in their case).

In the case of the official apps, there's no reason to go through OAuth, because in order to get an OAuth authentication token, you have to enter your username and password anyway. In the case of the official apps, that would make this redundant, and unnecessary.

The official apps could also be speaking to a dedicated set of authentication servers that only accept logins from the mobile app, the mobile app might be providing some special, extra information that identifies it as the official app, or some other mechanism on top of username and password for authentication. I'm not a Facebook developer, so I don't know. But my point is, Facebook/Twitter probably have a separate API password-based logins, and that API is only accessible by the web interface, and other official modes of login.

So, in your case, if you're building a social network (or any web service that will have mobile access) simply use the standard password-based login for your official app, but don't make that login method available to everyone. If you want to allow for 3rd party access through an API, you will really need to setup an OAuth/XAuth server to do this, in terms of keeping your users' passwords only under your control (and not leaked out to 3rd party groups/sites/apps).

jefflunt
  • 33,527
  • 7
  • 88
  • 126
  • Thanks, this was quite convenient. I was looking for a way around building a proprietary authentication method because it is usually easy to crack those algorithms in the mobile clients we are shipping. Anyway, probably I'll use that approach. – ahmet alp balkan Nov 08 '11 at 00:12
  • I think that's good advice, not to roll your own authentication mechanism. There are plenty of quality, open source solutions for every level of authentication. I can't help you specifically with mobile libraries to do this, but there is very likely one out there for your platform that is well respected (and community-reviewed) for security practices. – jefflunt Nov 08 '11 at 15:16