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

From: Justin Hart <[email-masked]>
Date: Mon, 9 Nov 2009 09:28:23 -0700

This is a response to an older thread by Eran, but I think some of the
topics brought up recently are related.

On Tue, Oct 6, 2009 at 3:07 PM, Eran Hammer-Lahav <[email-masked]>wrote:

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

I think the complaint is that you're 'exposing' client credentials to a
browser if you don't use some sort of temporary request token between the
user authorization and the 'approved' usage.  Essentially its between #1 and
#2 above, where the user goes directly to a webpage for authorization and
returns to the app with some temporary (request) token which is exchanged
for the 'access' token.  This takes the pre-webpage request step out.  It
changes the requirements on the web page request to display the client name,
and associate a user with the client, that we currently get through the
request token now (solved by supplying the client key).

One use case I've considered is the device-without-input case.  A device
contacts service for a request token, and gets a short (typable) token to
input on a web browser for authorization.  The device then reuses that token
to get an access token (which is probably longer and untypable) for
subsequent authorized requests.  I see the netflix device authorization as
being an example of how this could look.  Maybe 1.0a changes this flow
though - since its essentially the reverse (go to a site and get a token to
keypad into the device).

Does removing the pre-web-authorization token remove the risk covered in
1.0a? (The callback verification is still nice for the above case though)

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

It'd be nice, though for independents, HTTPS can be pricey. I doubt
Wordpress or Drupal would be able to promote it for independent self-hosted
users because most wont buy a HTTPS hosting package on their shared hosting
site.  I know some sites have been slow to implement much HTTPS because of
the high CPU cost of HTTPS sessions, and they're running tight on their
current hardware.  Probably best as a SHOULD and not a MUST.  But, that
means there needs to be some independently-secure way to exchange info.

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

I think there was some debate on whether exposing the user credential
token/secret is a risk overall?  If an attacker has the client credentials,
they could just direct a user through this process themselves, so what are
we protecting?

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

I assume this PK is in context to the method OAuth works currently with the
consumer_secret?  What's shared secret then?  I guess I dont know the
distinction yet.

---

From: Dick Hardt <[email-masked]>
Date: Tue, 10 Nov 2009 03:28:41 +0000

On 2009-11-09, at 8:28 AM, Justin Hart wrote:

It'd be nice, though for independents, HTTPS can be pricey. I doubt Wordpress or Drupal would be able to promote it for independent self-hosted users because most wont buy a HTTPS hosting package on their shared hosting site.  I know some sites have been slow to implement much HTTPS because of the high CPU cost of HTTPS sessions, and they're running tight on their current hardware.  Probably best as a SHOULD and not a MUST.

I agree with the SHOULD vs MUST.

But, that means there needs to be some independently-secure way to exchange info.

How secure do you mean by secure? Unless you duplicate HTTPS functionality, you will not be as secure. Do we need to be any more secure then what session cookies in a browser provide? If so, why?

-- Dick