Subject: [OAUTH-WG] Remove client credentials from protected resource requests

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 09:27:09 -0700

We seem to have consensus around dropping the client credentials from protected resource requests, using only the token (with optional secret or key) to authenticate the request. This means clients will be free to share tokens with other clients without the server being able to authenticate the client.

Client authentication is already a problematic feature in 1.0 as it only works for web-based applications capable of keeping the client credentials secret. WRAP dropped it to support crypto-free client experience. It is currently optional in 1.0.

I would very much like us to drop client credentials from protected resources requests, but want to make sure people are aware of the consequences. I plan to drop it in my first draft of the Token scheme.

EHL

---

From: Leah Culver <[email-masked]>
Date: Wed, 2 Dec 2009 08:46:09 -0800

One issue with dropping client credentials may be that it's more difficult
for providers to identify the client.

For example, Twitter might be using the client credentials to add "from
Tweetie" to their tweet meta data. This is just an example, I have no idea
if this is how Twitter identifies clients.

Do any providers have a problem with this? Is there another way to identify
clients? Should the client information be saved server-side with the token
data for future reference?

I'm okay with dropping the client credentials but I'd like to make sure we
still address this use case via other mechanisms.

Thanks!
Leah

On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav <[email-masked]>wrote:

> We seem to have consensus around dropping the client credentials from
> protected resource requests, using only the token (with optional secret or
> key) to authenticate the request. This means clients will be free to share
> tokens with other clients without the server being able to authenticate the
> client.
>
> Client authentication is already a problematic feature in 1.0 as it only
> works for web-based applications capable of keeping the client credentials
> secret. WRAP dropped it to support crypto-free client experience. It is
> currently optional in 1.0.
>
> I would very much like us to drop client credentials from protected
> resources requests, but want to make sure people are aware of the
> consequences. I plan to drop it in my first draft of the Token scheme.
>
> EHL
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: George Fletcher <[email-masked]>
Date: Wed, 02 Dec 2009 12:11:39 -0500

I'm more concerned with replay than the ability to identify the client. 
Basically, dropping this requirement means that the short lived bearer 
tokens are replay-able not only by the client that received them but 
also by any one who sees them (hence the need for SSL in WRAP).

Other mechanisms can be employed to identify the "client" (i.e. mutual 
TLS) but they require rather closed deployment models. However, that may 
be OK for those cases where this is required.

This doesn't solve the twitter/tweetie case. Though I'm not sure how 
well the current solution solves it either (meaning it's probably pretty 
easy for someone to extract the consumer token and secret from tweetie 
source code). Note that twitter could modify their API to provide this 
capability if critical to their model.

I do think that a signing profile should be supported, in addition to 
the bearer token model, for those cases that care about replay and some 
assurance that the entity that received the token (from the token 
issuer) is the entity presenting the access_token. This doesn't directly 
identify the client but does constrain replay scope. This is a critical 
requirement for some of our APIs.

Thanks,
George

Leah Culver wrote:
> One issue with dropping client credentials may be that it's more 
> difficult for providers to identify the client.
>
> For example, Twitter might be using the client credentials to add 
> "from Tweetie" to their tweet meta data. This is just an example, I 
> have no idea if this is how Twitter identifies clients.
>
> Do any providers have a problem with this? Is there another way to 
> identify clients? Should the client information be saved server-side 
> with the token data for future reference?
>
> I'm okay with dropping the client credentials but I'd like to make 
> sure we still address this use case via other mechanisms.
>
> Thanks!
> Leah
>
>
> On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     We seem to have consensus around dropping the client credentials
>     from protected resource requests, using only the token (with
>     optional secret or key) to authenticate the request. This means
>     clients will be free to share tokens with other clients without
>     the server being able to authenticate the client.
>
>     Client authentication is already a problematic feature in 1.0 as
>     it only works for web-based applications capable of keeping the
>     client credentials secret. WRAP dropped it to support crypto-free
>     client experience. It is currently optional in 1.0.
>
>     I would very much like us to drop client credentials from
>     protected resources requests, but want to make sure people are
>     aware of the consequences. I plan to drop it in my first draft of
>     the Token scheme.
>
>     EHL
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: John Panzer <[email-masked]>
Date: Wed, 2 Dec 2009 09:18:19 -0800

I'm +1 on dropping explicit support for client credentials in the protected
resource requests, because:

1. It is always possible to embed or reference a client ID in the opaque
token sent along with the request, so no fundamental functionality is lost
-- servers can always recover the data needed to add "from Tweetie";
2. It simplifies accessing the protected resource;
3. (Speculative) I think it simplifies possible extensions to allow for
controlled sub-delegation from one client to another.

--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Ethan Jewett <[email-masked]>
Date: Wed, 2 Dec 2009 12:20:48 -0500

+1 to Eran's proposal.

The optional token secret/key constrains replay scope, I think.

Further clients are already free to share tokens with other clients.
They just need to share the token, the token secret, the consumer key,
and the consumer secret. This change (I believe) just gets rid of the
fiction that the existence of a consumer key and secret gives the
service provider some control over the actions of the client.

Ethan

On Wed, Dec 2, 2009 at 12:11 PM, George Fletcher <[email-masked]> wrote:
> tokens are replay-able not only by the client that received them but also by
> any one who sees them (hence the need for SSL in WRAP).
>
> Other mechanisms can be employed to identify the "client" (i.e. mutual TLS)
> but they require rather closed deployment models. However, that may be OK
> for those cases where this is required.
>
> This doesn't solve the twitter/tweetie case. Though I'm not sure how well
> the current solution solves it either (meaning it's probably pretty easy for
> someone to extract the consumer token and secret from tweetie source code).
> Note that twitter could modify their API to provide this capability if
> critical to their model.
>
> I do think that a signing profile should be supported, in addition to the
> bearer token model, for those cases that care about replay and some
> assurance that the entity that received the token (from the token issuer) is
> the entity presenting the access_token. This doesn't directly identify the
> client but does constrain replay scope. This is a critical requirement for
> some of our APIs.
>
> Thanks,
> George
>
> Leah Culver wrote:
>>
>> identify clients? Should the client information be saved server-side with
>> the token data for future reference?
>>

---

From: John Panzer <[email-masked]>
Date: Wed, 2 Dec 2009 09:20:51 -0800

I think that a client id is orthogonal to replay attacks -- if I can see a
client ID, why can't I copy it as easily as I could an opaque token and
replay it?

In other words, yes I agree that replay is a concern given other proposals,
but I don't see how this proposal itself changes the story.  (And I believe
the replay concern is mitigated sufficiently by the other arguments on the
other threads.)

On Wed, Dec 2, 2009 at 9:11 AM, George Fletcher <[email-masked]> wrote:

>> On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>

---

From: George Fletcher <[email-masked]>
Date: Wed, 02 Dec 2009 13:06:16 -0500

John Panzer wrote:
> I think that a client id is orthogonal to replay attacks -- if I can 
> see a client ID, why can't I copy it as easily as I could an opaque 
> token and replay it?
You are correct that client id/secret is orthogonal to replay attacks as 
in the current spec there is nothing that requires the access_token to 
be bound to the consumer token (though there is nothing stopping a 
provider from doing this). So a tight coupling is possible in the 
current spec though I don't know of anyone doing so.

It's not the id that protects replay scope but rather the secret (which 
of course is relatively easily discovered in client code) that proves 
the "client" can present that client id.

As Ethan pointed out, if a client wants to share it can, so removing the 
requirement and making it optional makes those sharing cases easier. So 
+1 to not making it mandatory.
>
> In other words, yes I agree that replay is a concern given other 
> proposals, but I don't see how this proposal itself changes the story. 
>  (And I believe the replay concern is mitigated sufficiently by the 
> other arguments on the other threads.)
I'm still not convinced that SSL + short-lived bearer tokens solve the 
replay "risk" problem.

Thanks,
George
>
> --
> John Panzer / Google
> [email-masked] <mailto:[email-masked]> / abstractioneer.org 
> <http://abstractioneer.org> / @jpanzer
>
>
>
> On Wed, Dec 2, 2009 at 9:11 AM, George Fletcher <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I'm more concerned with replay than the ability to identify the
>     client. Basically, dropping this requirement means that the short
>     lived bearer tokens are replay-able not only by the client that
>     received them but also by any one who sees them (hence the need
>     for SSL in WRAP).
>
>     Other mechanisms can be employed to identify the "client" (i.e.
>     mutual TLS) but they require rather closed deployment models.
>     However, that may be OK for those cases where this is required.
>
>     This doesn't solve the twitter/tweetie case. Though I'm not sure
>     how well the current solution solves it either (meaning it's
>     probably pretty easy for someone to extract the consumer token and
>     secret from tweetie source code). Note that twitter could modify
>     their API to provide this capability if critical to their model.
>
>     I do think that a signing profile should be supported, in addition
>     to the bearer token model, for those cases that care about replay
>     and some assurance that the entity that received the token (from
>     the token issuer) is the entity presenting the access_token. This
>     doesn't directly identify the client but does constrain replay
>     scope. This is a critical requirement for some of our APIs.
>
>     Thanks,
>     George
>
>     Leah Culver wrote:
>
>         One issue with dropping client credentials may be that it's
>         more difficult for providers to identify the client.
>
>         For example, Twitter might be using the client credentials to
>         add "from Tweetie" to their tweet meta data. This is just an
>         example, I have no idea if this is how Twitter identifies clients.
>
>         Do any providers have a problem with this? Is there another
>         way to identify clients? Should the client information be
>         saved server-side with the token data for future reference?
>
>         I'm okay with dropping the client credentials but I'd like to
>         make sure we still address this use case via other mechanisms.
>
>         Thanks!
>         Leah
>
>
>         On Wed, Dec 2, 2009 at 8:27 AM, Eran Hammer-Lahav
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 11:19:09 -0700

> -----Original Message-----
> From: John Panzer [mailto:[email-masked]]
> Sent: Wednesday, December 02, 2009 9:18 AM
 
> 1. It is always possible to embed or reference a client ID in the opaque token
> sent along with the request, so no fundamental functionality is lost -- servers
> can always recover the data needed to add "from Tweetie";

Yep. The server is free to encode whatever it wants inside the token or in its database with a token lookup. This works for both opaque and structured tokens, as well as server-issued or otherwise (which is outside the scope).

> 2. It simplifies accessing the protected resource;

It is required to support the plain bearer token use case which has been the most sought after feature lately.

> 3. (Speculative) I think it simplifies possible
> extensions to allow for controlled sub-delegation from one client to another.

This is not a requirement and while it does make it easier, clients are free (technically) to share tokens as well as their client credentials with others. This just makes it less offensive.
 
> One issue with dropping client credentials may be that it's more difficult for
> providers to identify the client.

It might not even be more work since the server can embed the client identity in the token and would save itself another database look up for the client credentials. The server always knows who it issued a token to in the first place. In addition, the Twitter example is useful to demonstrate an API where a large number of applications are desktop which means the client credentials can be considered a hint at best.

> -----Original Message-----
> From: George Fletcher [mailto:[email-masked]]
> Sent: Wednesday, December 02, 2009 9:12 AM

> Basically, dropping this requirement means that the short lived bearer tokens
> are replay-able not only by the client that received them but also by any one
> who sees them (hence the need for SSL in WRAP).

Requiring client credentials with a bearer token request misses the point anyway since the appeal of a bearer token is lack of crypto.

> be OK for those cases where this is required.

The client is still being identified when requesting a token. This is about being able to "ensure" that the client making the request is the same client who received the token. Of course, if the client shares its credentials, the whole assumption is broken.

> someone to extract the consumer token and secret from tweetie source
> code). Note that twitter could modify their API to provide this capability if
> critical to their model.

No. They just need to store client information as part of their token records.

> I do think that a signing profile should be supported, in addition to the bearer
> token model, for those cases that care about replay and some assurance that
> the entity that received the token (from the token

This has nothing to do with the question... which was, is a single set of credentials (token) enough. Whether those credentials include a secret or key is another matter.

EHL

---

From: Mike Malone <[email-masked]>
Date: Wed, 2 Dec 2009 11:29:49 -0800

I'm +1 on this proposal too. Sounds like most of the relevant points
have been made, but I'll reiterate that I think the bearer token
should be sufficient for authentication, and I think it will simplify
delegation significantly.

You're talking about dropping the key/secret. Does that mean we'd be
moving to a WRAP-like model that uses SSL? Without signing, the bearer
token becomes as good as a username/password. If there's no
secret/signature then all of the relevant info for forging a request
is sent along with every legitimate request. Am I missing something?

Mike

---

From: John Panzer <[email-masked]>
Date: Wed, 2 Dec 2009 11:36:59 -0800

Not to extend this thread without necessity (I'm still +1 on the proposal
for someone scanning):

On Wed, Dec 2, 2009 at 11:29 AM, Mike Malone <[email-masked]> wrote:

> token becomes as good as a username/password.

It's actually strictly better than username/password, albeit not quite as
good as TLS:

(a) It can be rotated without user involvement or pain, even every few
minutes, mitigating many attacks.
(b) It can be guaranteed not to be the same as the secret used for unrelated
services, which is a huge problem for passwords even if they're secure (your
password is only as secure as the _least_ secure service you use it on, and
regular users re-use passwords everywhere).
(c) The token can be capability-limited so as to mitigate damage of leaking;
e.g., I personally would nearly rather that Mint only had a token granting
read-only access to my financial information, even if not sent over SSL,
than having all of the usernames and passwords for all of my financial
institutions, even if they're sent over SSL.

> If there's no

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 16:04:41 -0700

> From: Mike Malone [mailto:[email-masked]]
> Sent: Wednesday, December 02, 2009 11:30 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG ([email-masked])
> Subject: Re: [OAUTH-WG] Remove client credentials from protected
> resource requests
> 
> I'm +1 on this proposal too. Sounds like most of the relevant points have
> been made, but I'll reiterate that I think the bearer token should be sufficient
> for authentication, and I think it will simplify delegation significantly.
> 
> secret/signature then all of the relevant info for forging a request is sent
> along with every legitimate request. Am I missing something?

No. We are talking about an authentication method with 3 options:

1. Use Token and optional symmetric secret sent in the clear (Bearer token) with or without TLS.
2. Use Token and a symmetric secret with a MAC-based algorithm signature. TLS not required for securing secrets, only for other reasons (privacy, MITM, etc.).
3. User Token and an asymmetric secret (private key) to sign the request. Server validates using the public key. TLC not required for securing keys, only for other reasons.

The server may issue any kind of token it wishes to support, or any combination of it. The client uses the method appropriate for the token type it received. The crypto algorithm is negotiable for #2 and #3.

A draft is coming shortly.

EHL

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Dec 2009 14:10:36 -1000

So this sounds like the token is a username by any other name?   
Instead of a username/password pair, we have a token/PSK pair?
--Richard

On Dec 2, 2009, at 1:04 PM, Eran Hammer-Lahav wrote:

> 2. Use Token and a symmetric secret with a MAC-based algorithm  
> signature. TLS not required for securing secrets, only for other  
> reasons (privacy, MITM, etc.).
> 3. User Token and an asymmetric secret (private key) to sign the  
> request. Server validates using the public key. TLC not required for  
> securing keys, only for other reasons.
>
> The server may issue any kind of token it wishes to support, or any  
> combination of it. The client uses the method appropriate for the  
> token type it received. The crypto algorithm is negotiable for #2  
> and #3.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 17:40:29 -0700

Yeah...

I have been working for the past two days on the introductory prose for this Token scheme, trying to nail what exactly I am proposing and how it is different from Basic/Digest.

Stay tuned.

EHL

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Wednesday, December 02, 2009 4:11 PM
> To: Eran Hammer-Lahav
> Cc: Mike Malone; OAuth WG ([email-masked])
> >> moving to a WRAP-like model that uses SSL? Without signing, the
> >> bearer token becomes as good as a username/password. If there's no
> > token type it received. The crypto algorithm is negotiable for #2 and
> > #3.
> >

---

From: Richard Barnes <[email-masked]>
Date: Wed, 2 Dec 2009 14:50:24 -1000

I'm pretty sure I've said this before, but I always understood the  
main difference to be that it works in a single RTT, using timing and  
nonces instead of the challenge/response of Digest.  That, and the  
signature covers a few different things.
--Richard

On Dec 2, 2009, at 2:40 PM, Eran Hammer-Lahav wrote:

> Yeah...
>
> I have been working for the past two days on the introductory prose  
> for this Token scheme, trying to nail what exactly I am proposing  
> and how it is different from Basic/Digest.
>
> Stay tuned.
>
> EHL
>
>>> and

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 17:55:07 -0700

>From a technical perspective, yes. But there is also the widely deployed user-agent behavior when encountering Basic which is problematic for using Basic with tokens. The proposed Plain method works very much like Basic but it doesn't "suffer" from existing experience.

EHL

> Sent: Wednesday, December 02, 2009 4:50 PM
> To: Eran Hammer-Lahav
> I'm pretty sure I've said this before, but I always understood the main
> difference to be that it works in a single RTT, using timing and nonces instead
> of the challenge/response of Digest.  That, and the signature covers a few
> different things.
> --Richard
> 
> 
> 
> 
> > for this Token scheme, trying to nail what exactly I am proposing and
> > how it is different from Basic/Digest.
> >
> > Stay tuned.
> >
> > EHL
> >
> >>>> I'm +1 on this proposal too. Sounds like most of the relevant
> >>>> points have been made, but I'll reiterate that I think the bearer
> >>>> token should be sufficient for authentication, and I think it will
> >>>> simplify delegation significantly.
> >>>>
> >>>> You're talking about dropping the key/secret. Does that mean we'd
> >>>> be moving to a WRAP-like model that uses SSL? Without signing, the
> >>>> secret/signature then all of the relevant info for forging a
> >>>> request is sent along with every legitimate request. Am I missing
> >>>> something?
> >>>