In facebook's desktop authflow, rather then giving you an access_token endpoint to call with a secret to exchange a callback and get an valid access_token, you instead call authorize and it will redirect the user to a login_success.html page on facebook.com with the access token in a fragment on that page. (see http://developers.facebook.com/docs/authentication/desktop )
Their idea is that if you can embed a browser and get the user to authenticate through it, you can inspect the url of the embedded browser and detect when it hits login_success.html and take the access token fragment and store it. However, what is interesting about that is that I can embed client_ids I stole from other desktop apps (and possibly other web apps if they don't protect against it) and generate valid access_tokens against other ids in my own desktop app. The user may notice the app they authorize isn't the one they are using because because facebook identifies the app with its name and icon on the authorize page. However if I'm being evil, i could social engineer the user some how like I could name my app the same as the one I'm stealing or something similar and use the same icon, and then I can get access tokens like I'm that app. Basically when it comes to desktop apps, Facebook can't for sure tell the difference between my desktop app and illegitimate one. If Facebook blocks entire apps or rate limits by them, then I can still DOS the app by using their client_id. It doesn't offer anymore application identity protection then just embedding a secret and using the OAuth 1.0a flow and embedding secrets. Facebook probably realizes this. Since you can mark your app as a desktop app and not a web app in your app settings, they probably realize this issue and know that you can't always trust the desktop clients so why even bother with secrets (probably good that they ask your app type upfront for this reason and it doesn't give a false sense of security by even having a secret). From an operations perspective for FB, it gives them less options to safely blacklisting desktop apps without taking out legitimate ones though. Zac Bowling @zbowling On Jun 14, 2010, at 10:00 AM, Jef Poskanzer wrote: > Yeah, what Ryan said. > > Also, > > On Jun 13, 1:40 pm, segphault <[email protected]> wrote: >> Facebook and Google Buzz both offer desktop-appropriate OAuth >> authentication flows which do not require a consumer secret key and do >> not require the user to go through a complicated copy/paste process. > > I'm curious what they are doing. Do they give up on identifying the > application and just identify the user?
