Subject: [OAUTH-WG] A token/secret alone is sufficient to authenticate a client as a delegate

From: "Manger, James H" <[email-masked]>
Date: Thu, 1 Oct 2009 00:21:11 +1000

OAuth authentication would be significantly improved by using a single id/secret, instead of a pair (consumer_key/secret and token/secret).

This does not reduce any functionality. The server has authenticated the client when it issues the access token so it can incorporate the client id (consumer_key) into the token if it wants. The token secret is only returned in response to a request authenticated with the client secret. Hence, subsequently authentication with just the token secret is still authenticating the client.

There are some substantial advantages:

1. Authenticated requests can be made from less trusted environments, as they only require a secret specific to one delegation (one user) -- they do not require continued access to the client's long term secret.
It should even be possible for a client to be partly implemented on a web site (where the client secret can be protected) and partly in javascript delivered to a user's browser. That is, do OAuth web delegation at the client web site, then the client can use that user's token secret from javascript in that user's browser. The client secret is never exposed to any user's browser.

2. Special cases to handle situations where there is no token/secret are eliminated. These cases use the single client id/secret that they have. This covers the initial request for temporary credentials, and also 2-legged scenarios.

3. Special cases to handle situations where there is no client id/secret are eliminated. For clients that cannot be authenticated (eg desktop clients), OAuth authentication would just use the token/secret without needing to encode blank or dummy values into the protocol.

4. Fits much more easily with every other authentication mechanism, which invariable use a single id/secret.

As an added bonus this would allow OAuth to get rid of the oauth_consumer_key parameter with its old & awkward terminology ("consumer" vs "client", and "key" vs "id").

The spec changes don't look huge: remove the oauth_consumer_key parameter, simplify the HMAC key, simplify the PLAINTEXT signature, adjust the examples. [I will offer to help make the text changes if it will help]

James Manger
[email-masked]
Identity and security team — Chief Technology Office — Telstra

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 30 Sep 2009 12:50:09 -0700

This is exactly where I am going with the upcoming draft. It moves the client credentials out of the authentication part and into the delegation part.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Manger, James H
> Sent: Wednesday, September 30, 2009 7:21 AM
> To: [email-masked]
> Subject: [OAUTH-WG] A token/secret alone is sufficient to authenticate
> a client as a delegate
> 
> OAuth authentication would be significantly improved by using a single
> id/secret, instead of a pair (consumer_key/secret and token/secret).
> 
> This does not reduce any functionality. The server has authenticated
> the client when it issues the access token so it can incorporate the
> client id (consumer_key) into the token if it wants. The token secret
> is only returned in response to a request authenticated with the client
> secret. Hence, subsequently authentication with just the token secret
> is still authenticating the client.
> 
> 1. Authenticated requests can be made from less trusted environments,
> as they only require a secret specific to one delegation (one user) --
> they do not require continued access to the client's long term secret.
> It should even be possible for a client to be partly implemented on a
> web site (where the client secret can be protected) and partly in
> javascript delivered to a user's browser. That is, do OAuth web
> delegation at the client web site, then the client can use that user's
> token secret from javascript in that user's browser. The client secret
> is never exposed to any user's browser.
> 
> 2. Special cases to handle situations where there is no token/secret
> are eliminated. These cases use the single client id/secret that they
> have. This covers the initial request for temporary credentials, and
> also 2-legged scenarios.
> 
> 3. Special cases to handle situations where there is no client
> id/secret are eliminated. For clients that cannot be authenticated (eg
> desktop clients), OAuth authentication would just use the token/secret
> without needing to encode blank or dummy values into the protocol.
> 
> As an added bonus this would allow OAuth to get rid of the
> oauth_consumer_key parameter with its old & awkward terminology
> ("consumer" vs "client", and "key" vs "id").
> 
> 
> The spec changes don't look huge: remove the oauth_consumer_key
> parameter, simplify the HMAC key, simplify the PLAINTEXT signature,
> adjust the examples. [I will offer to help make the text changes if it
> will help]
> 
> 
> 
> James Manger
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth