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

cspzhouroc <cspzhouroc@comp.polyu.edu.hk> Wed, 09 January 2013 06:49 UTC

Return-Path: <cspzhouroc@comp.polyu.edu.hk>
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 9FC7921F870A; Tue, 8 Jan 2013 22:49:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.372
X-Spam-Level:
X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152]
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 Ixw2ziqPVlV3; Tue, 8 Jan 2013 22:49:04 -0800 (PST)
Received: from mailhost2.comp.polyu.edu.hk (mailhost2.COMP.POLYU.EDU.HK [158.132.20.241]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4921F872C; Tue, 8 Jan 2013 22:49:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id 16B0A5039B; Wed, 9 Jan 2013 14:49:01 +0800 (HKT)
X-Virus-Scanned: amavisd-new at comp.polyu.edu.hk
Received: from mailhost2.comp.polyu.edu.hk ([127.0.0.1]) by localhost (mailhost2.comp.polyu.edu.hk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id R3Ym+Y1-TuWJ; Wed, 9 Jan 2013 14:48:59 +0800 (HKT)
Received: from webmail.comp.polyu.edu.hk (vlinux01.COMP.POLYU.EDU.HK [158.132.8.197]) by mailhost2.comp.polyu.edu.hk (Postfix) with ESMTP id C172E5039A; Wed, 9 Jan 2013 14:48:59 +0800 (HKT)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_a12d74b1654cfc6dec652402c6aa9444"
Date: Wed, 09 Jan 2013 14:49:00 +0800
From: cspzhouroc <cspzhouroc@comp.polyu.edu.hk>
To: zhou.sujing@zte.com.cn
In-Reply-To: <OF09F85034.34A94363-ON48257AEE.00243414-48257AEE.002458A9@zte.com.cn>
References: <OF09F85034.34A94363-ON48257AEE.00243414-48257AEE.002458A9@zte.com.cn>
Message-ID: <435c62cb0612b3756dbe040fa1791cdd@comp.polyu.edu.hk>
X-Sender: cspzhouroc@comp.polyu.edu.hk
User-Agent: RoundCube Webmail/10.5
Cc: oauth@ietf.org, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] 答复: 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:49:04 -0000

  

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 

On Wed, 9
Jan 2013 14:36:37 +0800, zhou.sujing@zte.com.cn wrote: 

> 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 
> > > 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