It's not really fair to call this an OAuth flaw, since it's just another instance of the 'trusted client' problem in security.
Essentially it's impossible to differentiate Twitter's own client on an untrusted platform since it will always be possible for 'malicious' client to behave exactly like Twitter's own client.
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.
OAuth has been called flawed by security experts because it's filled with trap holes for developers to fall into[1] and former developers who left the project[2].
Sure, but that's beside the point. OAuth does not attempt to deal with this problem. If you have the secret consumer token, then you are that consumer in the eyes of OAuth.
One technique that can help establishing "trusted client" on untrusted platform is TRCE (Trusted Remote Code Execution)[1]
The client is required to download a piece of code from server to compute a result given a challenge from server. You can embed all sorts of logic to validate the client per connection! Think of this as using virus for good :)
[1] I'm getting good at inventing 4 letter security acronyms :)
TRCE is fundamentally different from BD+ in that the the code is served remotely instead of locally. That means that the validation code can be changed per connection with unlimited variations. The only way to deal with TRCE is PSB (Perfect SandBox), which is not trivial to implement.
Twitter doesn't need to ban unauthorized clients. They can use the detected client info for QoS to give preferential treatment to their own client and render the rest in the "best effort" service class, which could make unauthorized clients appear to work but unreliably.
Essentially it's impossible to differentiate Twitter's own client on an untrusted platform since it will always be possible for 'malicious' client to behave exactly like Twitter's own client.