I can't see the purpose of "generated secret" by the client. I fear this is
going to lead down the same confusing path as the last thread on auth codes.
Essentially what you're asking for is a unique session ID per grant request.
If TLS is required across all connections to protect the generated secret/ID,
then this secret serves no security purpose. The token (and auth code
represented by it during the first leg) serves as the session ID anyway, so the
client-generated secret is redundant. Additionally you have to deal with the
provider rejecting secrets if they are not unique.
Such a secret would provide no identity guarantee beyond the "same session"
guarantee provided the token. Any application can use an existing client ID,
make up a secret, and authenticate. The server knows nothing more about the
identity of the client. Identity and secrets must be established outside the
OAuth handshake - at the same point where application identity data (icon,
name, owner) is managed.
On Apr 8, 2011, at 9:49 AM, Phil Hunt wrote:
> I am assuming the outbound requests are secured by TLS, but for various
> reasons the return path (e.g. the redirect) might not be. Thus, one
> restriction would be that the server never returns the code to the client.
>
> Thus, you could submit a secret simply for the purpose of verifying the same
> specific requestor for each operation.
>
> Phil
> phil.h...@oracle.com
>
>
>
>
> On 2011-04-08, at 9:36 AM, tors...@lodderstedt.net wrote:
>
>> This would be another possible standard option. As you pointed out, it would
>> help to detect authz code theft even for native apps. It would not help wrt
>> client authorization since there are no properties associated with the new
>> credential.
>>
>> The key is: how does the authz server get to know this secret? As the
>> redirects are not fully protected against leaks (history, referers) I would
>> not pass it in as a parameter to the authz request.
>>
>> Regards,
>> Torsten.
>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>>
>> -----Original Message-----
>> From: Phil Hunt <phil.h...@oracle.com>
>> Date: Fri, 8 Apr 2011 09:22:18
>> To: Skylar Woodward<sky...@kiva.org>
>> Cc: Torsten Lodderstedt<tors...@lodderstedt.net>; Kris
>> Selden<kris.sel...@gmail.com>; Zeltsan, Zachary
>> \(Zachary\)<zachary.zelt...@alcatel-lucent.com>;
>> oauth@ietf.org<oauth@ietf.org>
>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth
>>
>> 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
