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

zhou.sujing@zte.com.cn Fri, 11 January 2013 09:30 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 ECCE621F8790 for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2013 01:30:10 -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 yGQ5eyaI5Fzm for <oauth@ietfa.amsl.com>; Fri, 11 Jan 2013 01:30:09 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DEF4721F8445 for <oauth@ietf.org>; Fri, 11 Jan 2013 01:30:08 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 9B2E1127B78A; Fri, 11 Jan 2013 17:32:27 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r0B9TXJU039038; Fri, 11 Jan 2013 17:29:33 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <50EDAAFE.3050300@mitre.org>
To: Justin Richer <jricher@mitre.org>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF09D54669.8CAEF4ED-ON48257AF0.0033C8D1-48257AF0.003428F9@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Fri, 11 Jan 2013 17:29:14 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-01-11 17:29:27, Serialize complete at 2013-01-11 17:29:27
Content-Type: multipart/alternative; boundary="=_alternative 003428F848257AF0_="
X-MAIL: mse01.zte.com.cn r0B9TXJU039038
Cc: Peng Zhou <zpbrent@gmail.com>, oauth@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: Fri, 11 Jan 2013 09:30:11 -0000

Justin Richer <jricher@mitre.org> 写于 2013-01-10 01:38:06:

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

How is Client assured the UA actually went to AS and got something by the 
following URL?

A:
 GET/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz 
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
HTTP/1.1  Host: server.example.com
C:
HTTP/1.1302Found 
Location: https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA 
&state=xyz





  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  <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
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>