Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework

[cspzhouroc <[e-mail]>]

  

Dear Justin: 

Your answer is comprehensive and very helpful :-)


Great thanks :-) 

Best Regards 

Brent 

On Wed, 9 Jan 2013 12:38:06
-0500, Justin Richer wrote: 

> Brent,
> 
> If you're sending the code
in the back channel directly to the Client,
> as I believe you're doing
from your text below, I would like you to
> realize some things:
> 
> 1)
This is not OAuth, and is in fact antithetical to the OAuth way of
>
solving the connection problem.
> 2) You are actually lowering your
overall security because the access
> code is no longer bound to any
particular browser session with either
> the client or the AS.
> 3) If
you're sending it directly, there is no longer any point of using
> the
code, since the Client is just going to turn around and send it to
> the
AS again to get a token. Why not just send the token? But again,
> this
is still not OAuth.
> 
> Think about it this way: There are three
connections in the common OAuth
> Authorization Code scenario, which is
why it's known as a three-legged
> OAuth flow in many circles. Each of
these legs has unique properties, is
> protected by different things,
and is exposed to different pieces of
> knowledge at different times.
>

> 1) Client User Agent: protected by a local session of the Client's
>
choosing. For Web based clients this is often standard HTTP session
>
cookies or similar, potentially backed by a login of some type by the
>
user to the Client as well. This session is never exposed to the
>
Authorization Server.
> 2) Authorization Server User Agent: protected by
a local session of
> the Authorization Server's choosing, normally
through some kind of
> Primary Credential (login) that the user has a
the AS. Importantly,
> these credentials are never exposed to the
Client.
> 3) Client Authorization Server: protected by the client
credentials,
> which are, importantly, not exposed to the user or user
agent.
> 
> By sending the code as part of the redirect, the Client is
able to prove
> that the User Agent actually went to the Authorization
Server (2) and
> got something. The Authorization Code is then sent
through the bottom
> leg (3) of the channel to verify that it really did
come from the
> Authorization Server in the context of the user that was
just there in
> (1). In other words, this mechanism that you seem to be
avoiding is
> exactly what makes OAuth secure.
> 
> If you instead send
the code through (3), then the Client as no way at
> all of knowing that
the user in (1) ever went to the authorization
> server via (2). All the
Client knows is that they sent the user
> someplace and that a magic
code showed up. It is very, very, very
> dangerous and a very, very bad
idea to assume that a code coming in the
> back channel (3) has anything
at all to do with any particular session (1).
> 
> This approach does
*not* mitigate any real security threats, and in fact
> introduces a
great number of others, as described here. There are much
> better ways
to protect the Authorization Code, and most of the best
> practices are
enumerated in the security considerations document. Some
> of the most
common are:
> 
> 1) Make Authorization Codes one-time-use (even if you
try and fail, it's
> thrown away)
> 2) Make Authorization Codes time out
after a very short period (minutes
> or seconds)
> 
> I hope this
helps.
> 
> -- Justin
> 
> On 01/09/2013 01:42 AM, Peng Zhou wrote:
>>
Dear SuJing:
>> 
>> If it is the only reason, why we send the
authorization code to the
>> client directly and send another
notification without the
>> authorization code to the RO. This way can
mitigate the chance that
>> the authorization code is exposed to the
RO's user-agent, hence
>> protecting the authorization code from leaking
to possible attackers
>> in a higher security levle.
>> 
>> Best
Regards
>> Brent
>> 
>> 2013/1/9 :
>> 
>>> Then why not let auth code be
sent directly from AS to Client?
>>> 
>>> Just want to inform RO that an
auth code has been dilivered to Client?
>>> 
>>> [e-mail]
[8] 写于 2013-01-09 14:27:50:
>>> 
>>>> Hi Brent,
>>>> 
>>>> Few points,
why this doesn't create any security implications..
>>>> 
>>>> 1.
Authorization server maintains a binding to the Client, who the
>>>>
token was issued to. To exchange this to an Access token client
>>>>
should authenticate him self.
>>>> 2. Code can only be exchanged once
for an acces token.
>>>> 
>>>> Thanks & regards,
>>>> -Prabath
>>>> On
Wed, Jan 9, 2013 at 6:56 AM, cspzhouroc wrote:
>>>> Dear All:
>>>> 
>>>>
I have a question in the section 1.3.1. Authorization Code in
rfc6749
>>>> The OAuth 2.0 Authorization Framework.
>>>> 
>>>> It tells
"which in turn directs the resource owner back to the client
>>>> with
the authorization code."
>>>> 
>>>> Who can let me know the reason why
is the authorization code sent to
>>>> client through a redirection in
resource owner's agent? Any security
>>>> implications?
>>>> 
>>>> Is it
possible to let the authorization server send the authorization
>>>>
code to the client directly (not through resource owner's
user-agent)?
>>>> 
>>>> Best Regards
>>>> Brent
>>>> 
>>>>
_______________________________________________
>>>> OAuth mailing
list
>>>> [e-mail] [2]
>>>>
https://www.ietf.org/mailman/listinfo/oauth [3]
>>>> --
>>>> Thanks &
Regards,
>>>> Prabath
>>>> 
>>>> Mobile : [phone]
>>>> 
>>>>
http://blog.facilelogin.com [4]
>>>>
http://RampartFAQ.com_______________________________________________
[5]
>>>> OAuth mailing list
>>>> [e-mail] [6]
>>>>
https://www.ietf.org/mailman/listinfo/oauth [7]
>>
_______________________________________________
>> OAuth mailing list
>>
[e-mail] [10]
>> https://www.ietf.org/mailman/listinfo/oauth
[11]
> 
> _______________________________________________
> OAuth
mailing list
> [e-mail] [12]
>
https://www.ietf.org/mailman/listinfo/oauth [13]

  

Links:
------
[1]
mailto:[e-mail]
[2] mailto:[e-mail]
[3]
https://www.ietf.org/mailman/listinfo/oauth
[4]
http://blog.facilelogin.com
[5]
http://RampartFAQ.com_______________________________________________
[6]
mailto:[e-mail]
[7]
https://www.ietf.org/mailman/listinfo/oauth
[8]
mailto:[e-mail]
[9] mailto:[e-mail]
[10]
mailto:[e-mail]
[11]
https://www.ietf.org/mailman/listinfo/oauth
[12]
mailto:[e-mail]
[13] https://www.ietf.org/mailman/listinfo/oauth