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 >
- [OAUTH-WG] A question of 1.3.1. Authorization Cod… cspzhouroc
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… Prabath Siriwardena
- [OAUTH-WG] 答复: Re: A question of 1.3.1. Authoriza… zhou.sujing
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… Prabath Siriwardena
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… cspzhouroc
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… cspzhouroc
- [OAUTH-WG] 答复: Re: 答复: Re: A question of 1.3.1. A… zhou.sujing
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… cspzhouroc
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… Prabath Siriwardena
- [OAUTH-WG] 答复: Re: A question of 1.3.1. Authoriza… zhou.sujing
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… Prabath Siriwardena
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… Phil Hunt
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… cspzhouroc
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… cspzhouroc
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… Phil Hunt
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… cspzhouroc
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… Phil Hunt
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… cspzhouroc
- Re: [OAUTH-WG] A question of 1.3.1. Authorization… Peng Zhou
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… Peng Zhou
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… Justin Richer
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… cspzhouroc
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… zhou.sujing
- Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Autho… Richer, Justin P.