Subject: [OAUTH-WG] Username and Password Flow and oauth_client_secret

From: Tosh Meston <[email-masked]>
Date: Wed, 28 Apr 2010 13:26:15 -0700

Hi everyone,
I see that in draft specification, under the username and password flow,
the oauth_client_secret is not listed in the required or optional request
parameters, but is included in the example request.  Is it correct to assume
it should be listed it in the required parameters?

POST /access_token HTTP/1.1 Host:
server.example.comoauth_client_identifier=s6BhdRkqt3&oauth_client_secret=8eSEIpnqmM&oauth_username=daveman692&oauth_password=1password

http://www.ietf.org/mail-archive/web/oauth/current/msg01396.html#anchor9

Thanks,
Tosh

---

From: David Recordon <[email-masked]>
Date: Wed, 28 Apr 2010 17:19:32 -0400

Hey Tosh,
I think this example just needs updating. In most cases the username and
password flow will be used on applications or devices which can't keep
secrets. Thus specing that the oauth client secret is used is a poor idea
from a security perspective. I imagine that different devices will be able
to keep secrets in different manners and that this will be used in a more
case by case basis.

--David

On Wed, Apr 28, 2010 at 4:26 PM, Tosh Meston <[email-masked]> wrote:

> POST /access_token HTTP/1.1 Host: server.example.comoauth_client_identifier=s6BhdRkqt3&oauth_client_secret=8eSEIpnqmM&oauth_username=daveman692&oauth_password=1password
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Tosh Meston <[email-masked]>
Date: Wed, 28 Apr 2010 18:01:53 -0700

Hey David,
Thanks for the response and clarification.  Agreed.  The mobile device
shouldn't keep the client secret so passing in the body in an SSL request is
out, and signing the /access_token request is out for the same reason.  So,
it doesn't seem like there is a way to ensure that value in the
oauth_client_identifier really represents that client, if I understand
correctly.  Is that an issue?

Evil client X could get an access_token and token_secret for another app,
but would only be able to make successful calls to protected resources if
the platform failed to check if the app represented by the
oauth_client_identifier is the same app represented by the
oauth_consumer_key, and also used the oauth_client_identifier as the
application id.

Just thinking aloud and trying to get my brain around this...

Thanks!
Tosh

On Wed, Apr 28, 2010 at 2:19 PM, David Recordon <[email-masked]> wrote:

> On Wed, Apr 28, 2010 at 4:26 PM, Tosh Meston <[email-masked]>wrote:
>
>> Hi everyone,

---

From: David Recordon <[email-masked]>
Date: Wed, 28 Apr 2010 23:28:45 -0400

I realize that this doesn't work generically, but at Facebook we only plan
to offer the username/password flow to a small number of partners. We figure
that we'll work out device/app authentication on a case by case basis
depending on what is possible. We've also thought about issuing clients a
separate secret which only works on this flow and couldn't be repurposed for
other flows if it were to be stolen.

I believe Google is going to solve this problem by not supporting the
username/password flow in the first place.

--David

On Wed, Apr 28, 2010 at 9:01 PM, Tosh Meston <[email-masked]> wrote:

> On Wed, Apr 28, 2010 at 2:19 PM, David Recordon <[email-masked]>wrote:
>
>> Hey Tosh,

---

From: Allen Tom <[email-masked]>
Date: Thu, 29 Apr 2010 10:21:18 -0700

As an additional datapoint, Yahoo only offers the equivalent of the
username/password flow (using our proprietary token auth API) for a very
small number of partners, and only when using a browser not feasible.

Allen

On 4/28/10 8:28 PM, "David Recordon" <[email-masked]> wrote:

> I realize that this doesn't work generically, but at Facebook we only plan to
> offer the username/password flow to a small number of partners.
> 
> [...]
>