How are Facebook authenticating/authorizing their official native clients?

Question

Lets stick with Facebook for this example.

I am asuming that FB uses it's own public API's (as well as internal ones, that only they can use), and as they are using OAuth 2, would it be safe to assume they have "special client registrations" with permission to use the Resource Owner Password Credential Grant?

As you may know, when logging into Facebook from their own official apps, they don't pop open a browser, asking you if you allow Facebook to use Facebook, so if they are using OAuth themselves, how are they doing this securely?

We've all read that Twitter got their consumer keys leaked, how are Facebook avoiding this?

I am no security expert, nor do I have experience in reverse engineering, I am just in a situation where I am to implement an OAuth authorization server myself, and we wish to expose our API's to 3rd parties, but as we ourselves have "official native apps", we'd like to use the Resource Owner Password Credential grant, for the best user experience.

As per the OAuth 2 spec, native apps should not include client secrets, but how does that make things better? The way I see it, if you don't include the secret, and your client ID is extracted and used for password grants, the only way you can revoke it is by completely removing the client ID from your authorization server.

Am I missing something obvious here? How do "the big guys" do this?

Dromedary

What client are you refering to? (download link) – Moneymaking

@Moneymaking their iOS/Android/WP clients. – Dromedary

Answer 1

The big difference is, that the official Facebook app knows your username and password and therefore don't need to pop a browser, because they can directly authenticate.

As a third party app, I cannot (ok, I could, but for privacy reasons I won't) ask for the users email and password. As official app, you can do this and thus directly perform a login (this may happen through an undocumented REST endpoint)

Rouge

But do they save your credentials, or do they use oauth password grant? – Dromedary

If oauth, how do they prevent client credentials leakage? – Dromedary

I just monitored the FB-App with Fiddler. They seem to use their own OAuth with password grant, but I don't know, if they store the users credentials, or if the use another way. However, I believe, that they store them, because it seems to be the easiest way. – Rouge

Awesome, thats exactly what I was looking for! I don't suppose you could see the contents of the password grant response? I think they use refresh tokens, anything else would go against everything they stand for; security. – Dromedary

I found something official: developers.facebook.com/docs/facebook-login/access-tokens "Native mobile applications using Facebook's SDKs will get long-lived access tokens, good for about 60 days. These tokens will be refreshed once per day when the person using your app makes a request to Facebook's servers." So they don't store credentials. – Rouge

So no refresh tokens? Each request returns a new access token, or is the current tokens lifetime extended? I am mostly interested in how they prevent client credential theft - that is, Facebook's official apps' credentials, so others cant steal them and authenticate users and have them think it is the official app. I hope you know what I mean. :) – Dromedary

No refresh tokens. As far as I know the tokens are bound to a session (facebook.com/…) in their database and on requesting a new token, the old token will be replaced by a new one. And because no credentials are stored, it'll be hard to steal them. – Rouge

But what about Facebook's client ID and secret? The OAuth spec says the secret should not be stored on a user device, so if they were stolen (as happened to Twitter), they would be screwed, so I was wondering, if it has not happend to them yet, how do they grant themselves more privilegde than 3rd party apps without fear of their client secrets being leaked? – Dromedary

You don't need a client secret for client applications. The client secret is only for server side applications relevant. – Rouge

It's weird, why is that? If you can just omit it in client apps, whats the point in a secret? The client id is public so how do they ensure only they can use it? Thats the gist of the question :) – Dromedary

Let us continue this discussion in chat. – Rouge

Would be nice if you could provide updates in case there are any additional findings. Considering the findings in the comments (using password grant and not undocumented REST endpoint), the marked answer doesn't really answer the question. – Centralia

Excellent question but sadly this answer does not actually answer the question. It should be unmarked in my opinion. It would be very interesting to find out how the "big boys" do this. Having a public client allowed to get ROPG tokens doesn't seem like a "risk" though. The risk is those third-party applications should never ask for first-party credentials (usernames and password). Spoofing the "official" client id doesn't solve this risk because a malicious app could just make a lookalike Facebook app to steal credentials, not even calling the first-party APIs. – Dilisio