Certain apps that have a web view potential could do it by redirecting to
the provider, but yes, this is the point that Ed and I were making that
desktop apps have a big problem navigating the workflow (first going to the
provider with a browser, and second, looking for the credentials; most apps
will be constrained, and some apps can't start a browser at all).
However, Alex stated in a previous message that they are considering some
legacy options for desktop applications; I imagine we'll hear more about
that as the OAuth formal rollout becomes imminent.
Usual "I don't speak or work for Twitter" applies.
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Quote me as saying I was misquoted. -- Groucho Marx ------------------------
With all due respect, *not* all modern environments do this seamlessly. How
would a script in somebody's cron job do that? Or a text-mode client? They
all have to authenticate and they are not in an environment where a browser
is easily available, if it is available at all.
Even for those apps that do have the ability to open a browser, which I grant
will be many and possibly even most, it does present a UX problem with
differing interfaces and it may be hard for some apps to *find* the generated
credentials to use.
Noteworthy things on this topic, from Google of all companies:
"Authorizing rich-client devices without a web browser"
"UX research on desktop apps using federated login and/or OAuth"
These are not easy problems to solve, and even Google does not have a
-- With a rubber duck, one's never alone. -- Douglas Adams, "HGTTG" -----------
Citation please :)
-- The less we know, the better we feel. -- David Bowie, "Miracle Goodnight" --
>> For an end user, OAuth is generally speaking much friendlier for
>> pretty much
>> every application type, iPhone, desktop, or web.
> From my chair, OAuth is a fantastic solution to authenticate *other
> web apps*. OAuth anywhere else, desktop, iPhone, laundry machine,
> makes me want to chip away a hole in my skull with a dull screwdriver,
> jab a straw into my head, and drink my own brain matter.
> 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.
> Ok, I'm holding myself back from ranting. I guess my point is this:
> OAuth sucks hardcore for everything except other web apps.
> Oh, and Twitter guys: I can't thank you guys enough for keeping around
> basic auth. Thank you thank you thank you.
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.
-- I use my C128 because I am an ornery, stubborn, retro grouch. -- Bob Masse -
From a user perspective I find it confusing and awful. I
second the "chip hole in skull" comment. I'd love to see
some research on the topic, though, maybe it's just me.
Popping up a browser control inside the app (on the iPhone
WebKit allows you to do this) appears to be a superior (but still
kinda weak) solution, with no loss in actual security.
I too am thankful that plain-old-password-based auth is
sticking around for when it's appropriate.
 Well, there was that link Cameron Kaiser posted:
but I mean some research that supports the idea that it's
all fine and ok, not research that suggests it's an ugly hack
that ruins usability. I especially liked the quote "The flow
makes some security people happy because the user
never enters their password into the client application.
However it makes usability much much worse, and any
evil client application on most operating systems can do
other evil things to the user's computer anyways such
as installing malware.". Well, duh. Thanks for the link,
Christopher St. John
Alex Payne - API Lead, Twitter, Inc.