5 ms·

> OAuth just doesn't work with locally installed applications That's not really true, Twitter just has a broken model where they want to authenticate the appli

by codeka 14y ago

> OAuth just doesn't work with locally installed applications That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user... The rest of your comment is quite spot on, though. This is going to be a cat and mouse game for Twitter and I'm not sure they can win.

martius 14y ago
> Twitter just has a broken model where they want to authenticate the application as well as the user... Can you elaborate? As far as I understand how it works, this is the case by design in OAuth. (edit: typo)
pifflesnort 14y ago
> That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user... No, it is still true. There's no point, at all, to OAuth on a native client. Native clients can: 1) Present fake browser chrome 2) Present no browser chrome 3) Inject their own scripts into the webview to acquire the username/password 4) Extract the browser username/password from the keychain ... and so on. Enforced OAuth is simply a case of web developers foisting complexity onto native developers because they don't appreciate the goals and priorities in the native app problem domain.
- cscheid 14y ago
  > There's no point, at all, to OAuth on a native client. As far as I understand it, you're right, except when OAuth is the only authentication mechanism provided and you want to, you know, develop a desktop app. Of course, providing OAuth as the only authentication mechanism appears then to be the problem. But that is not a problem application writers can solve; it seems to be a problem that OAuth deployers have to deal with.
- pixelcort 14y ago
  The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client. This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able to get the cleartext password and log into other unrelated services with it.
  - xyzzy123 14y ago
    Thanks, this. Also, because the access token for each app is unique, you can grant different account permissions to your apps so you can in principle limit their access to your account. Also there is more accountability. If an access token gets leaked or misused you at least have a chance of figuring out where it came from. OAuth is usually a better choice for API authentication than username/password, even for desktop apps.
    - pifflesnort 14y ago
      If you want to limit their access to your account, uninstall the application. No more access. If you're worried about genuinely nefarious applications, OAuth ought to be the least of your worries, because it's not going to protect you.
  - pifflesnort 14y ago
    > The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client. Why does this matter? If you compromise somebody's desktop or phone, you're in an extremely privileged permission. This means that you can spy on their authentication processes while they are occurring. Including processes that occur on the web. You can also read the user's keychain, containing the saved passwords for the OAuth service that you're trying to protect.
    - csense 14y ago
      Depends on the level of compromise. If an attacker can interface to the screen and keyboard, or access other process's memory to directly read the key from there, or spoof the SSL library so you get cleartext network transmissions, sure, they can steal a lot of data. But if the attacker only has access to the filesystem, then it certainly matters whether the filesystem contains enough information to impersonate a user. And there are things that people do to desktops that allow other people to access their filesystems. Things like cloud backup, sending your computer in for repairs, or selling an old hard drive. Sure, you should remove the hard drive or wipe it before you do any of these things, but a lot of people...don't. There are plenty of stories about that situation floating around the interwebs, but this comment is long enough...

by codeka 14y ago

martius 14y ago

> Twitter just has a broken model where they want to authenticate the application as well as the user... Can you elaborate? As far as I understand how it works, this is the case by design in OAuth. (edit: typo)

pifflesnort 14y ago

> That's not really true, Twitter just has a broken model where they want to authenticate the application as well as the user... No, it is still true. There's no point, at all, to OAuth on a native client. Native clients can: 1) Present fake browser chrome 2) Present no browser chrome 3) Inject their own scripts into the webview to acquire the username/password 4) Extract the browser username/password from the keychain ... and so on. Enforced OAuth is simply a case of web developers foisting complexity onto native developers because they don't appreciate the goals and priorities in the native app problem domain.

cscheid 14y ago
> There's no point, at all, to OAuth on a native client. As far as I understand it, you're right, except when OAuth is the only authentication mechanism provided and you want to, you know, develop a desktop app. Of course, providing OAuth as the only authentication mechanism appears then to be the problem. But that is not a problem application writers can solve; it seems to be a problem that OAuth deployers have to deal with.
pixelcort 14y ago
The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client. This way if the device on which the native client lives is compromised, the attacker won't be able to obtain the cleartext password, unless it was compromised during the OAuth login process. Sure, the attacker will get the token, but they won't be able to get the cleartext password and log into other unrelated services with it.
- xyzzy123 14y ago
  Thanks, this. Also, because the access token for each app is unique, you can grant different account permissions to your apps so you can in principle limit their access to your account. Also there is more accountability. If an access token gets leaked or misused you at least have a chance of figuring out where it came from. OAuth is usually a better choice for API authentication than username/password, even for desktop apps.
  - pifflesnort 14y ago
    If you want to limit their access to your account, uninstall the application. No more access. If you're worried about genuinely nefarious applications, OAuth ought to be the least of your worries, because it's not going to protect you.
- pifflesnort 14y ago
  > The nice thing about OAuth on a native client is that it allows a non-evil client the option of not storing the cleartext password in a recoverable way on the client. Why does this matter? If you compromise somebody's desktop or phone, you're in an extremely privileged permission. This means that you can spy on their authentication processes while they are occurring. Including processes that occur on the web. You can also read the user's keychain, containing the saved passwords for the OAuth service that you're trying to protect.
  - csense 14y ago
    Depends on the level of compromise. If an attacker can interface to the screen and keyboard, or access other process's memory to directly read the key from there, or spoof the SSL library so you get cleartext network transmissions, sure, they can steal a lot of data. But if the attacker only has access to the filesystem, then it certainly matters whether the filesystem contains enough information to impersonate a user. And there are things that people do to desktops that allow other people to access their filesystems. Things like cloud backup, sending your computer in for repairs, or selling an old hard drive. Sure, you should remove the hard drive or wipe it before you do any of these things, but a lot of people...don't. There are plenty of stories about that situation floating around the interwebs, but this comment is long enough...