On 03/22/2013 12:48 PM, Chris Steipp wrote:
I think the caricature of OAuth there should be taken
with a grain of
salt. The author talks about "OAuth", but seems to be referring to
OAuth 2 primarily, which is very different from OAuth 1. Also, the
author says that the protocol was designed for authorizing
website-to-website communication, but then says it's insecure in a
desktop app environment, which it is. They also point to the (very
good) article about using OAuth for authentication, which again, the
protocol was not designed for.
I agree. There are valid issues with OAuth, but the article is way over
the top, and some of the statements, like:
"Third party software cannot run automated processes on an OAuth APUI."
are flat out false.
That's exactly how services like IFTTT and Zapier work. They require a
one-time authentication step, then can run in the background automated
forever (or until revoked).
"A web site can embed a web browser via a Java Applet or similar, or
have a web browser server side which presents the OAuth log in page to
the user, but slightly modified to have all the data entered pass
through the third party site. Therefore OAuth doesn't even fulfill its
own primary security objective!"
is a bit silly, since Java applets are increasingly being sandboxed and
just completely disabled/uninstalled, and some users can certainly tell
the difference between a weird Java browser and a popup in their main
browser.
The biggest real issue is probably the optional components, but I sense
that sites are already forming de facto profiles (i.e. new sites
gravitate toward particular components).
"Also it is common that OAuth implementations are using security tokens
which expire, meaning the boss will need to keep reentering his Calendar
credentials again and again."
I don't know any one that requires you to enter your password again.
Some require automatic token renewal, and with others (again, an
increasing number, based on what I can see) the token lasts until
revocation.
Matt Flaschen