W3C home > Mailing lists > Public > public-social-web-talk@w3.org > January 2009

Re: About Twitter and OAuth (and trusted mashups?)

From: Blaine Cook <romeda@gmail.com>
Date: Sun, 25 Jan 2009 15:49:08 +0100
Message-ID: <d37b4b430901250649x2e230bcbob3d1afc30de253f4@mail.gmail.com>
To: David Larlet <larlet@gmail.com>
Cc: public-social-web-talk@w3.org

On Sun, Jan 25, 2009 at 12:46 AM, David Larlet <larlet@gmail.com> wrote:
>
> There are a lot of false assertions in this article (see Stuart Dallas'
> comments), the worse part is comparing OpenID to OAuth although they are
> complementary!

The persistent confusion of OAuth and OpenID is problematic, though I
don't see very many examples of this, and they are complementary in
that for API-dependent sites, OpenID isn't a viable option without a
delegated auth. protocol (e.g., OAuth).

> Furthermore, OAuth does not improve security (nor trust) at
> all, it just allows fine grained access to resources/data. Nothing more.

That's completely untrue. OAuth significantly improves the security
and trust of sites that use HTTP Basic auth for API access. Some
examples:

- The consumer key/secret allows the service provider to identify and
treat as trusted consumers who are able to keep their consumer key
secret (i.e., sites that do not distribute the consumer key/secret).

- Passwords (and cookies) can be sniffed. For Twitter, this means
every few minutes when you're on public wifi (or shared/hacked closed
wifi). OAuth makes this impossible (short of guessing the consumer
secret and token secret).

- Replay or spoofed requests require brute-forcing HMAC-SHA1. Almost
nil possibility in the next 5-10 years. The protocol allows for
additional signature methods, and as such can be updated if attacks
against HMAC-SHA1 are discovered.

- OAuth allows sites to use preventative tools against phishing (e.g.,
identity seal images) that are not possible with Basic Auth.

- The psychological factor of asking users to give permission to
limited subsets of their data instead of wholesale access to their
account should not be underestimated.

- OAuth makes it possible to use devices that do not have input
methods (e.g., digital picture frames), since the device can request a
token and display a URL for the user to provide authorisation.

- By not using passwords, OAuth makes it easier to use tools like
1Password and more-random passwords, since users are not required to
remember their passwords in all sorts of different situations.

There are plenty more places where OAuth helps markedly improve
security. It's not a panacea, and care must be taken when implementing
systems that use it. However, it *does* improve security, and to say
otherwise is misleading and harmful to overall progress towards web
security.

Full disclosure, I'm a primary author of the OAuth spec; that said, I
don't care as much about particular specifications or implementations,
I'm more interested in the overall security of the web --- delegated
authentication is one clear route to improvement.

b.
Received on Sunday, 25 January 2009 17:43:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:51:47 UTC