IMHO OAuth doesn't work for desktop applications because all the aspects where it tries to provide more security than traditional username/password authentication are easily circumvented on the desktop.
As such OAuth on the desktop IMHO is not much more than snake oil and does nothing aside of increasing the complexity for the implementer while providing next to zero additional security.
First is client authentication: OAuth tries to authenticate clients as well as users. On a desktop it's not possible to authenticate clients because whatever they do, the information can be extracted and simulated by a malicious client.
The other thing is that by now many desktop OAuth clients embed a webview for the authentication handshake. There is no way for the user to be sure that they are typing their credentials into the site they think they are. There is no browser chrome, there is usually no URL bar and even if there was, there is zero trust that the URL is actually showing the correct URL.
Worse: How many client apps are actually going through the trouble of checking SSL certificates (or even that SSL is on)?
Embedding a webview for an OAuth handshake provides (to the user) no additional security compared to just showing a username/password dialog.
The only way how I see this actually work is if the application opens the default browser for the handshake. But of course that will show a big-ass security warning when redirecting back to the local url protocol.
In consequence this means that the only method by which OAuth on the desktop could provide additional security is the one method that presents a security warning to the user. How ironic.
All of the points you've made about poor SSL security could just as easily be made against software that communicate over SSL using a username and password. At least with OAuth, there's only potential for a username/password leak on sign in—after that only the revokable token could be leaked.
It doesn't help in the Twitter client use case, but it will help in the user/password compromise scenario described in the parent comment.
If I compromise the keytab, I can impersonate the domain member server and presumably the active tickets... but the username/password is on the KDC/DC.
As such OAuth on the desktop IMHO is not much more than snake oil and does nothing aside of increasing the complexity for the implementer while providing next to zero additional security.
First is client authentication: OAuth tries to authenticate clients as well as users. On a desktop it's not possible to authenticate clients because whatever they do, the information can be extracted and simulated by a malicious client.
The other thing is that by now many desktop OAuth clients embed a webview for the authentication handshake. There is no way for the user to be sure that they are typing their credentials into the site they think they are. There is no browser chrome, there is usually no URL bar and even if there was, there is zero trust that the URL is actually showing the correct URL.
Worse: How many client apps are actually going through the trouble of checking SSL certificates (or even that SSL is on)?
Embedding a webview for an OAuth handshake provides (to the user) no additional security compared to just showing a username/password dialog.
The only way how I see this actually work is if the application opens the default browser for the handshake. But of course that will show a big-ass security warning when redirecting back to the local url protocol.
In consequence this means that the only method by which OAuth on the desktop could provide additional security is the one method that presents a security warning to the user. How ironic.