Re: [OAUTH-WG] Report an authentication issue

[Phil Hunt <[e-mail]>]

We need more info on the inject method the researchers used before we can account for it. 

Phil

On 2012-06-29, at 12:16, John Bradley <[e-mail]> wrote:

> The same thing can be done with code.
> 
> If the token endpoint checks the client_id before giving out the access token then the attack on code can be prevented, as the token endpoint won't return the access token.
> 
> The spec dosen't require authenticating public clients currently so it is a slightly more difficult attack but possible.
> 
> Dick and I are suggesting closing the hole at the token endpoint so that nether confidential nor public clients using the code flow are susceptible to this substitution attack.
> 
> John B.
> 
> On 2012-06-29, at 2:53 PM, PhiIt helps with the code flow when l Hunt wrote:
> 
>> I'm not seeing how client id helps if a proxy server is somehow involved with inserting the bearer token as the researchers suggested. 
>> 
>> Phil
>> 
>> On 2012-06-29, at 11:30, John Bradley <[e-mail]> wrote:
>> 
>>> I think they only exploited the implicit flow.   
>>> 
>>> My point was that there is a way you could do the same thing with code if it is a public client that is not authenticating to the token endpoint.
>>> 
>>> In general making identity assumptions in the client based on a code or access_token has risks that are out of scope for OAuth.
>>> 
>>> We do however want to provide good advice about specific things that can leave systems insecure when using OAuth.
>>> 
>>> John B.
>>> 
>>> On 2012-06-29, at 2:22 PM, Phil Hunt wrote:
>>> 
>>>> I'm not clear whether the MS Security Researcher hack was with the authorization code or the access token. If the latter, the client_id is out of the picture isn't it?
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> [e-mail]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 2012-06-29, at 11:14 AM, Dick Hardt wrote:
>>>> 
>>>>> 
>>>>> On Jun 29, 2012, at 11:06 AM, John Bradley wrote:
>>>>> 
>>>>>> It is nice to know that I may occasionally be correct:)
>>>>> 
>>>>> You must be delighted when it happens! ;)
>>>>> 
>>>>>> While you may assume that it is reasonable for a client with a code to make a request to the token endpoint including it's client_id and the server to only give out the access token if the client_id in the token request matches the one in the original authorization request.   However the spec specifically doesn't require that.
>>>>> 
>>>>> I think that is an error in the spec and should be changed, or text adding saying that the client_id SHOULD be checked.
>>>>> 
>>>>> -- Dick
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>> 
>