Why not have the client app generate a random text string to be used as a
request secret. The random text string would be matched during all subsequent
requests by the client surrounding a particular authorization. Assuming the
endpoints all require TLS for request side operations it would prevent
interception issues and bind the authz code to a particular client instance
even when matching client credentials are used by an intercepting hacker.
Would this help to satisfy at least some of the client app instance
identification issues?
Note: it had also occurred to me that client apps should have static
client_instance identifiers. In practical terms this might be tied to an IMEI
number for example on a smart phone or other static information. However, I
don't think it would solve this security issue since it would be easy to
imitate. The above solution suggests a changing random string instead.
Phil
phil.h...@oracle.com
On 2011-04-08, at 12:10 AM, Skylar Woodward wrote:
> Yes, I can see how this might seem confusing. Actually, we're authenticating
> the client with authorization server - not a resource request. On the MAC
> threads we discussed how the token can be used for both. Hopefully that
> clears everything up, but I'll briefly address some of the questions inline.
>
> On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote:
>
>> Hi Skylar,
>>
>> Am 06.04.2011 18:02, schrieb Skylar Woodward:
>>> Well, I should elaborate. The method of authorization is open to the
>>> client, and in this case (Kiva), MAC tokens are being used. The client
>>> authenticates on the access_token request by presenting a MAC
>>> authentication header. Creating the MAC signature requires a secret. In the
>>> native client case, since there is no secret, it signs with the empty
>>> string. So, how would you interpret this mechanism? Are we using an empty
>>> string secret or signing without a secret? In terms of communicating to the
>>> developers, they are told they don't have a secret. For purposes of
>>> signing, they are instructed to sign with them empty string when they have
>>> no secret.
>>
>> You are talking about using the client secret to authenticate resource
>> server request, correct? This is not in scope of the core spec. I was
>> talking about authenticating the client with the authorization server.
>>
>> Apart from that, do you think singing with an empty string adds any security
>> to your solution?
>
> No. It's about congruence at this point. Also, a MAC token by definition is
> signed so it has to be some other assertion if it is not signed.
>
>> Moreover as far as I understand the MAC-Spec, it recommends to use
>> authorization server issued secrets to sign the request. So why do you need
>> a client secret for request signing?
>>
>>> Alternatively, one could use Bearer token for client authentication in this
>>> case where the token is just the client ID. To me this is more confusing
>>> because they must authenticate with different token types for secret vs.
>>> non-secret. Other opinions?
>>
>> I'm confused now, why is the token the client id? A token is used by the
>> authorization server and may contain (or refer to) any data you need to
>> authorize access of the client to the resource server.
>
> Right, you're confusing the spec with the use. I'm considering the case of a
> simple Bearer assertion in cases of client authentication where clients have
> no secret since an ID/password assertion would imply an empty-string password
> or secret. As Marius said, we're splitting hairs at this point. Section 3.1
> makes no notes on the possible value of client_secret for clients w/o
> secrets, so the assumption was that a value of "client_secret=&..." would be
> ignored resulting in an invalid Client Password submission.
>
>>
>>> As to the question of interoperability, the fact that OAuth allows freedom
>>> of choice to the AS for method of authentication makes this point moot.
>>> Would you agree? (short of various providers could pooling together to
>>> standardize on an auth method outside of the spec).
>>
>> What authentication are you refering to? Who do you want to authenticate?
>
> Client authentication. Section 3.2.
>
>>
>> regards,
>> Torsten.
>>
>>>
>>>
>>> On Apr 4, 2011, at 10:15 PM, tors...@lodderstedt.net wrote:
>>>
>>>> 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® Webmail von Telekom Deutschland
>>>>
>>>> -----Original Message-----
>>>> From: Skylar Woodward<sky...@kiva.org>
>>>> Date: Mon, 4 Apr 2011 19:14:53
>>>> To: Torsten Lodderstedt<tors...@lodderstedt.net>
>>>> Cc: Zeltsan, Zachary (Zachary)<zachary.zelt...@alcatel-lucent.com>; Kris
>>>> Selden<kris.sel...@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-boun...@ietf.org [mailto:oauth-boun...@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.sel...@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
>
> _______________________________________________
> 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
