> The basic purpose of OAuth is to allow access to Twitter without > having to give out your password.
Hmmm... you are giving out your password, just in a different window. Look, I know the difference. And you know the difference. But I'm betting a lot of people don't know why that's different. Only that it's harder. > Twitter *can not* verify this unless > the user authorizes through one of their properties which currently is > web only. I get your drift. But the user experience of basic auth **is** simpler. And that's what users expect. We can't exactly put the genie back in the bottle on that one. Users already have simple desktop clients. >> You might want to look at the new PIN based OAuth flow under desktop >> clients: http://apiwiki.twitter.com/Authentication >> >> I did. I couldn't envision how this was supposed to work in a real- >> world >> app. I've read about it dozens of times. It seemed to me that it >> was maybe >> intended for mobile? Does anyone know of another shipping, real- >> world >> desktop app that uses this mechanism for user-authentication? >> > > Check out Yammer's ( https://www.yammer.com/ ) desktop application. > They use pin based OAuth for their own service. I don't know of a > Twitter desktop app that currently users PIN based auth but it is the > same flow. I don't want to be too vocal for fear that the developer of that app is on this board too. Perhaps there were some good reasons for their UI choices that aren't apparent to me in the 10 minutes I gave it. But... um, that isn't exactly a straight-forward UI. The "enter code" box has, literally, 5 lines of text explaining what you're supposed to do. Twitteriffic has this: "Please sign in using your Twitter account information." I guess I'm aiming for the later. >> I'm not developing desktop OSX applications yet but I am all for more >> opensource code. >> >> If the suggested pattern is "open a browser for every login" then >> my demo >> here is pretty much pointless. So there's no reason to bother >> opening my >> code. I'll just give up, go back to basic mode, praying twitter >> doesn't >> shut it off. The "open a browser every time" is not a reasonable >> alternative. It would give old apps that are grandfathered into >> basic >> authentication such a significant usability advantage that it would >> not be >> worth attempting a competitor. >> If an in-app-web-view is viable, then I'll continue down this road >> and >> release this as open in a week or so. >> > > Something to keep in mind is if Twitter changes their authorize page > it could brake apps using in-app-web-view until a new version can be > shipped. In theory someone who never reinstalls OSes or applications > could use an application for years with only performing the jump to > browser dance once. Adding a serious deficiency to the first-run experience when compared to the currently entrenched players of any product is a sure fire way to garantee failure. I think the prudent choice would be to do basic auth and switch when the entrenched players are forced to switch too. At least then it's an even playing field. Isaiah
