Re: [OAUTH-WG] Flowchart for legs of OAuth

+1 for making the specification clear. It should say that the native application clients participating in the authorization code flow do not use the client secrets. 

Zachary
-----Original Message-----
From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net] 
Sent: Tuesday, April 05, 2011 1:15 AM
To: Skylar Woodward
Cc: Zeltsan, Zachary (Zachary); Kris Selden; oauth@ietf.org
Subject: AW: Re: [OAUTH-WG] Flowchart for legs of OAuth

Hi Skylar,

Thank you for sharing this information with us. Some thougts:

The empty string makes your implementation syntactically compliant but does obviously not comply with its semantics and the security considerations/expectations associated with a secret. Moreover, what about interoperability? 

I think not using secrets for such clients is the honest solution. We can just change the spec's text to express what we think is the right way.

regards,
Torsten.
Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland  

-----Original Message-----
From: Skylar Woodward <skylar@kiva.org>
Date: Mon, 4 Apr 2011 19:14:53 
To: Torsten Lodderstedt<torsten@lodderstedt.net>
Cc: Zeltsan, Zachary (Zachary)<zachary.zeltsan@alcatel-lucent.com>; Kris Selden<kris.selden@gmail.com>; oauth@ietf.org<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

In our implementation (not yet public) we accept the empty string ("") as the value for clients not issued secrets. While this was done to simplify the interface and implementation, it would make it compliant in my view.  In this case, the authorization server is validating the credentials, which are the client ID and the empty string, which is equivalent security-wise to any other length of "secret" issued to a native client.

Besides, for many providers, the client credentials will only be a client ID. They would plan to secure all exchanges over TLS and credentials serve just as a tracking device or at best, a weak form of identification.

skylar

On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote:

> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary):
>> According to section "6 Refreshing an Access Token" (-13.txt), client when making a request for exchanging a refresh token for an access token has to include its authentication credentials, and the "authorization server MUST validate the client credentials".
>> How can this be done if a client is an application that can't have a client secret?
>> The authorization code grant does require client authentication (per section 4.1):
>> 
>> (D)  The client requests an access token from the authorization
>>         server's token endpoint by authenticating using its client
>>         credentials, and includes the authorization code received in the
>>         previous step.
>> 
>> It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens.
> 
> In my opinion, this part of the spec is misleading. Authorization code MUST be possible without client authentication. Otherwise, OAuth is useless for native apps.
> 
> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01#section-2.10 describes how the flow can be protected in such cases.
> 
> regards,
> Torsten.
>> Zachary
>> 
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Marius Scurtescu
>> Sent: Monday, April 04, 2011 2:30 PM
>> To: Kris Selden
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
>> 
>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden<kris.selden@gmail.com>  wrote:
>>> A typical iPhone app cannot be shipped with a client secret and rightly or wrongly users expect to only have to enter their credentials once.
>>> 
>>> What is the best profile to use for an app that can't have a client secret and needs a refresh token or a long lived access token?
>> The authorization code grant, aka web server flow.
>> 
>> The spec is misleading in this respect IMO.
>> 
>> Marius
>>_______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>_______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>_______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth