Re: [OAUTH-WG] Delegation (token) requests

[Blaine Cook <romeda at gmail.com>]

2009/10/6 Eran Hammer-Lahav <eran at hueniverse.com>:
> There are three well-defined methods for obtaining a token:
>
> Many large providers I talked to would like to have #1 to get rid of the temporary credentials (request token). The vast majority of the temporary credentials are never used and waste resources. The 3-steps flow was created to address clients which are unable to receive redirections and therefore have no way to get the token back from the server.

The wasted resources argument is a red herring. I'd like to see some
math supporting that argument, because frankly, in a world where
Google can afford to scan and host 10 million books using 10 MP
digital photos (that's ca. 1 billion 16 MB files), they (and Yahoo)
can (easily) afford to store a few million tokens. These tokens can be
safely expired within an hour.

> Many developers have asked for #3 for cases where it is perfectly acceptable for an application to have access to the user's credentials, but still provide a single OAuth-based API. This has been also raised in cases where opening a browser is poor or unacceptable user experience.

I have yet to see a study suggesting that opening a browser is
actually a poor or unacceptable user experience. I've seen developers
complain about it, but I have yet to see a credible report from an
actual user that it's a difficult experience, or results in dropped
conversion rates. I'd love to see Flickr's numbers on this, as they
could have gone the username / password route, but chose to go with
the browser redirect flow for their own iPhone app, and I've seen
nothing but positive reviews there.

I'm not saying that I'm 100% opposed to this flow. What I am saying is
that the arguments being used for it are bunk, and I want those making
them to provide real evidence for their claims. We're talking about
changing the protocol here, and the burden is on those interested in
changing it to support their arguments.

> Questions:
>
> - Are there use cases where the 3-step flow (#2) is needed?

Yes. There are a number of apps using it. YouTube, Flickr (the flow,
not specifically OAuth), Netflix (see their XBox integration), and
virtually all desktop-based Twitter applications. Desktop apps that do
not want to take a password or *can't* take a password (e.g., digital
picture frames, devices without keyboards or screens) require the
3-step flow.

> - Should we require use of HTTPS for token requests?

It should remain as-is, a SHOULD, but those sites that cannot / will
not support HTTPS obviously need a way to use OAuth.

> - If it is ok for tokens to be sent unsecure, is it also ok to send client secrets unsecure?

Client secrets distributed to devices or desktops must always be
assumed to be compromised. They're inherently not protectable (see:
DeCSS etc). Client secrets sent to 3rd party services where there is a
reasonable assumption that those services can maintain secrecy *must*
be sent over secure channels.

> - How should a PK option work? What should be signed? How should it work over a secure channel?

As far as I'm concerned, the fact that the PK option doesn't involve
signing the token secret was an oversight and should be corrected to
be the same as the HMAC-SHA1 flow.

b.