> I'm still not buying it that oauth is going add any value for desktop > clients with regards to password security. Basically you are now storing > token in the desktop client instead of password.
The added security is that either your malicious app, or, say some trojan in the user's computer, cannot grab the token and get full user privileges. If you store password, they can log on, change the password and email on the account, and cause all other sorts of trouble. with oAuth, the damage is limited to one user/app combination, they cannot grab the token and change, say, the user's email address on file. (Looks like the user's email address is not exposed anywhere in the API, and that's a good thing.) The user can clearly see what apps have permission to act on their behalf, and can revoke access app-by-app, instead of having to change the password in all apps. A more practical example of improved security is that in the past, I have myself had instances where I have changed my twitter password, but forgot to change it in apps using basic auth. And apps are implemented crappily (OTHER people's apps, but never yours, right? ;) and do not check response when signing in and keep hammering the API with wrong password. End result - my account is locked out due to what looks like bruteforce hacking, and I need to go and reset it. Doable, but annoying. There are other benefits, but these two are very obvious and practical. Deprecating Basic Auth in favor of OAuth will be painful for both Twitter and lazy/bad developers (if you are a good developer, OAuth won't really bother you at all), but I commend Twitter for doing this. J -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
