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

zhou.sujing@zte.com.cn Wed, 09 January 2013 06:52 UTC

Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58521F8750; Tue, 8 Jan 2013 22:52:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.55
X-Spam-Level:
X-Spam-Status: No, score=-93.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJCxZBJoIOrp; Tue, 8 Jan 2013 22:52:13 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3E19F21F874C; Tue, 8 Jan 2013 22:52:12 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 425E9A3814; Wed, 9 Jan 2013 14:52:00 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B5735704EF4; Wed, 9 Jan 2013 14:41:48 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r096pmPl043583; Wed, 9 Jan 2013 14:51:48 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <CABFKGseLf3=P79YmJmBQ_vt1xqb+v2RSMn6sc6WWPPGff43ing@mail.gmail.com>
To: Peng Zhou <zpbrent@gmail.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFEB0A72B4.D2CE86C3-ON48257AEE.00253B11-48257AEE.0025B771@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Wed, 09 Jan 2013 14:51:35 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-09 14:51:45, Serialize complete at 2013-01-09 14:51:45
Content-Type: multipart/alternative; boundary="=_alternative 0025B76F48257AEE_="
X-MAIL: mse01.zte.com.cn r096pmPl043583
Cc: oauth-bounces@ietf.org, oauth@ietf.org
Subject: [OAUTH-WG] 答复: Re: 答复: Re: A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Jan 2013 06:52:17 -0000

I am just guessing......expecting others answer here. 
On the other hand, auth code exposed to RO does not have security 
implication, 
as far as I know:
1. if auth code is transported in plaintext, it should require CLient 
authentication to use it.
2. if auth code  do not need Client authentication , auth code could be 
sent in encryption

Peng Zhou <zpbrent@gmail.com> 写于 2013-01-09 14:42:09:

> 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  <zhou.sujing@zte.com.cn>:
> >
> > 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?
> >
> > oauth-bounces@ietf.org 写于 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 
<cspzhouroc@comp.polyu.edu.hk
> >> > 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
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> >>
> >
> >>
> >> --
> >> Thanks & Regards,
> >> Prabath
> >>
> >> Mobile : +94 71 809 6732
> >>
> >> http://blog.facilelogin.com
> >> http://RampartFAQ.com_______________________________________________
> >
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth