> > No, seriously. When I launch a desktop app, I want to type in my > > username and password. That's it. If I launch a Twitter client on my > > iPhone, I don't want to have to quit the frickin' app to authenticate > > in Safari, then go *back* to the app when I'm done. Sure I could > > bring up an embedded web view, but UIWebView is a flakey hunk of junk, > > and it's no more secure than letting the user type the password into a > > native field directly because I would *own the web view and can get at > > any info the users types in anyway*. > > See the Darkslide iPhone app for a nice implementation of this. When > you touch the log in button it opens mobile Safari where you log in > and authorize the app. Mobile Safari then closes and you are taken > back to Darkslide where you are now logged in. > > I have no idea how this is done from a programming perspective, > however, from a user perspective it works well IMHO. > > > Hell, it's not even any more secure on the desktop... I just install a > > key listener and wait for you to type in a password into your browser.
But Loren's security points still hold -- an allegedly OAuth-compliant app doesn't have to do it that way, and as he says, he still owns any control his code puts on the screen. Besides, if you've already got your code running on their local system, who cares about OAuth? Let's riffle their files! :) My other objections are the same, so I won't repeat them. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * [email protected] -- I use my C128 because I am an ornery, stubborn, retro grouch. -- Bob Masse -
