Re: [OAUTH-WG] 答复: Re: A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework
Justin Richer <jricher@mitre.org> Wed, 09 January 2013 17:38 UTC
Return-Path: <jricher@mitre.org>
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 45E8D21F84E4 for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 09:38:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.691
X-Spam-Level:
X-Spam-Status: No, score=-2.691 tagged_above=-999 required=5 tests=[AWL=-3.387, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 62BPXqG9OUji for <oauth@ietfa.amsl.com>; Wed, 9 Jan 2013 09:38:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 467BC21F8610 for <oauth@ietf.org>; Wed, 9 Jan 2013 09:38:10 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C24471F2763; Wed, 9 Jan 2013 12:38:09 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id AE8451F04A5; Wed, 9 Jan 2013 12:38:09 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 9 Jan 2013 12:38:09 -0500
Message-ID: <50EDAAFE.3050300@mitre.org>
Date: Wed, 09 Jan 2013 12:38:06 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Peng Zhou <zpbrent@gmail.com>
References: <CAJV9qO80r93oOk-EjVukF0AUbc5-FWu8VhpVi+9WZBGzSjMrPA@mail.gmail.com> <OF09F85034.34A94363-ON48257AEE.00243414-48257AEE.002458A9@zte.com.cn> <CABFKGseLf3=P79YmJmBQ_vt1xqb+v2RSMn6sc6WWPPGff43ing@mail.gmail.com>
In-Reply-To: <CABFKGseLf3=P79YmJmBQ_vt1xqb+v2RSMn6sc6WWPPGff43ing@mail.gmail.com>
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [129.83.31.58]
Cc: 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: Wed, 09 Jan 2013 17:38:22 -0000
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 <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.