Re: [OAUTH-WG] Why give the redirect URI when trading an access code for an access token?

[Torsten Lodderstedt <[e-mail]>]

  thank you for the clarification.

What about mobile/desktop applications utilizing the web flow? I 
wouldn't assume such clients to use per-application client secrets 
because protecting these secrets is impossible (as stated in §2 of draft 
-10).

I wonder whether instance-specific secrets (obtained via dynamic client 
registration) could help here.

regards,
Torsten.

Am 11.09.2010 16:59, schrieb Eran Hammer-Lahav:
> Sorry.
>
> 7. Evil user takes the code and gives it back to the client by constructing the original correct redirection URI.
> 8. Client exchanges the code for access token, attaching it to the evil user's account.
> 9. Evil user can now access victim user data on his client account.
>
> This is basically a session fixation attack.
>
> EHL
>
>> -----Original Message-----
>> From: Torsten Lodderstedt [mailto:[e-mail]]
>> Sent: Saturday, September 11, 2010 1:01 AM
>> To: Eran Hammer-Lahav
>> Cc: Freeman, Tim; [e-mail]
>> Subject: Re: [OAUTH-WG] Why give the redirect URI when trading an access
>> code for an access token?
>>
>>    Doesn't step 7 require the evil user to know the client's secret?
>>
>> Am 10.09.2010 17:06, schrieb Eran Hammer-Lahav:
>>> 1. Evil user starts the OAuth flow on the client using the web-server flow.
>>> 2. Client redirects the evil user to the authorization server, including state
>> information about the evil user account on the client.
>>> 3. Evil user takes the authorization endpoint URI and changes the
>> redirection to its own site.
>>> 4. Evil user tricks victim user to click on the link and authorize access
>> (phishing or other social engineering attack).
>>> 5. Victim user thinking this is a valid authorization request, authorizes
>> access.
>>> 6. Authorization server sends victim user back to the client, but since the
>> redirection URI was changed, back to the evil user site.
>>> 7. Evil user grabs the code and exchanges it for an access token.
>>>
>>> By checking that the callback URI used to deliver the code is the same as
>> the one used to initiate the flow, the authorization server can verify that the
>> user who initiated the flow is the same one to authorize access and finish the
>> flow.
>>> EHL
>>>
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of Freeman, Tim
>>>> Sent: Wednesday, September 08, 2010 8:05 PM
>>>> To: [e-mail]
>>>> Subject: [OAUTH-WG] Why give the redirect URI when trading an access
>>>> code for an access token?
>>>>
>>>> Hi.  I'm new here.  I searched the archives a bit and didn't
>>>> immediately find an answer to my question below.  My apologies if
>>>> there was some previous discussion of this that I missed.
>>>>
>>>> Looking at the draft spec at
>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-10,
>>>> I see in section 4.1.1 "Authorization code" on page 22 that it is
>>>> required to give the redirect_uri of the original request when
>>>> exchanging an authorization code for an access token, and the
>>>> authorization server must verify that the redirection URI is correct as well
>> as the authorization code.
>>>> Based on section 4.2 "Access Token Response" on page 25, it seems
>>>> that the redirect_uri is not used when constructing the response from
>>>> the authorization server.
>>>>
>>>> So far as I can tell, the redirect_uri is useless in this request.
>>>> It does not contain any secrets.  The authorization code is verified
>>>> and is meant to be an arbitrary unguessable identifier, so little is
>>>> gained by verifying the redirect_uri also.  It is not used to construct the
>> reply.  Why is it required?
>>>> Tim Freeman
>>>> Email: [e-mail]
>>>> Desk in Palo Alto: [phone]
>>>> Home: [phone]
>>>> Cell: [phone]
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth