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

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 6 Oct 2009 14:07:17 -0700

There are three well-defined methods for obtaining a token:

1. Web Delegation (2 steps) - user is redirected to the server, authorizes, redirected back to client with token.
2. Web Delegation (3 steps) - client obtains temporary credentials, user authorizes at the server, client exchanges temporary credentials for token.
3. Direct Request - client uses the user's username and password to request for a token.

OAuth Core 1.0 supports the #2 option only. There is clear demand for the other two methods.

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.

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.

When making a token request, the client may be required to authenticate itself (using its client credentials). The authentication method is either a shared secret or PK-based.

When sending a token, the server should use a secure channel to ensure the token credentials remain confidential.

When using a shared-secret over a secure channel, there is no reason to sign the request and simply including the secret is enough. If a PK is used, the request has to be signed in some way even over a secure channel (because there is nothing else to send with the request).

Questions:

- Are there use cases where the 3-step flow (#2) is needed?
- Should we require use of HTTPS for token requests?
- If it is ok for tokens to be sent unsecure, is it also ok to send client secrets unsecure?
- How should a PK option work? What should be signed? How should it work over a secure channel?

EHL

---

From: Ethan Jewett <[email-masked]>
Date: Fri, 9 Oct 2009 17:59:53 -0500

Some thoughts on this:

#1 vs. #2

Going with #1 as the standard and #2 as an optional extension makes sense to me.

#3

With regards to #3, I'm skeptical of the existence of common use cases
where it is acceptable for an app to have access to a user's
credentials. I have seen a lot of these bandied about, but they
usually amount to "The app/website is made by a trusted party, so it's
ok for the user to provide his/her password."

I think there are a couple of issues here:

1) Why should the party be trusted if the same thing can be
accomplished without trusting the party with the credentials. Most of
the Twitter account hijackings have been because people have trusted
untrustworthy apps with their credentials. The fact seems to be that
"trusted" = "everybody else is doing it". I don't think we should make
this an option in this case.

2) This argument is often made in the case of official apps for
websites. In this case the argument is incorrect in my opinion. The
app (and by extension the trusted party) does not control the platform
so the app cannot inherit the trust associated with the trusted party.

Are these the use-cases that you had in mind? Am I being too
methodologically pure here?

Security in the transport layer for token exchange:

It seems that in a client that can actually protect the consumer
secret it is a nice bonus to be able to pass tokens in the clear and
dispense with the overhead of SSL/TLS.

For clients that can't protect the consumer secret (any installed
application), then yes, I think it makes a lot of sense to require a
secure connection for the token exchange. Should it also be made
explicit that the consumer secret can be dispensed with in this
situation?

Ethan

On Tue, Oct 6, 2009 at 4:07 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Blaine Cook <[email-masked]>
Date: Sun, 11 Oct 2009 10:05:47 +0100

> 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. Th…

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 a…

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.

> - 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.

---

From: Pelle Braendgaard <[email-masked]>
Date: Tue, 13 Oct 2009 15:59:45 -0400

> safely expired within an hour.

I have to agree with Blaine about the wasted resources issue. However
anything that can be done to simplifying the process for developers
without infringing on security is a step up. People are unfortunately
still very confused about the 3 step process. So I would not mind this
as the default implementation, but I'd probably still want the 3 step
for when its a better fit.

I am also completely against the username password approach. This goes
completely against what OAuth is about.
> not support HTTPS obviously need a way to use OAuth.

I do prefer https, but as Blaine says we should leave it in. It would
be a good idea to create an official list of best practices separate
from the official standard.

> be the same as the HMAC-SHA1 flow.

Agreed. How though. Adding it to the SBS? Doing a hmac signature first
(- consumer secret) and then signing that with the key?

BTW. Here is an interesting thread on the Twitter Dev list showing
some of the issues developers perceive rightly or wrongly about OAuth:

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/c4a8637359b25683

P

-- 
http://agree2.com - Reach Agreement!
http://extraeagle.com - Solutions for the electronic Extra Legal world
http://stakeventures.com - Bootstrapping blog