3 ms·
How does using the OAuth flow on a desktop app solve any of these issues? If you have the app binary, you have the secret key. It's simply a matter of attachin
by fleitz 15y ago
How does using the OAuth flow on a desktop app solve any of these issues?
If you have the app binary, you have the secret key. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability.
- saurik 15y agoThe OAuth 2.0 flow, as far as I can tell, does not require you distributing your secret key, which is what this application was doing. From Facebook's documentation: "The app secret is available from the Developer App and should not be shared with anyone or embedded in any code that you will distribute (you should use the client-side flow for these scenarios)."
- nl 15y agoIf you have the app binary, you have the secret key. No, you have the access token. There's a big difference. It's simply a matter of attaching a debugger and waiting for the URL handler to be called. Even the trick auth flow on iphone where it opens the Facebook app has the same vulnerability. Yep, you can do that. But then all you know how to authorize the app to act on your (the logged on user) behalf. You can write another application that pretends to be that app, but since it acts on your behalf I'm not sure that's a big risk. In the case of this KDE program, not only do you know how to make the app act on your behalf - but (as the OP noted) - it is probably possible to make the application act on behalf of any other user that has authorized this application id. That's a pretty bad problem. It sucks for the legitimate users who uploaded the pics using it, but who knows what else got uploaded to other people's accounts using this program? I suspect that's the reason why Facebook didn't just bad the app, but had to delete pics as well.