Re: [OAUTH-WG] A question of 1.3.1. Authorization Code in rfc6749 The OAuth 2.0 Authorization Framework
Phil Hunt <phil.hunt@oracle.com> Wed, 09 January 2013 07:31 UTC
Return-Path: <phil.hunt@oracle.com>
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 1F21221F87AC for <oauth@ietfa.amsl.com>; Tue, 8 Jan 2013 23:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 awXLYx1mqDLT for <oauth@ietfa.amsl.com>; Tue, 8 Jan 2013 23:31:34 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 090D821F870A for <oauth@ietf.org>; Tue, 8 Jan 2013 23:31:33 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r097VR6R029985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Jan 2013 07:31:28 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r097VPEY019489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Jan 2013 07:31:25 GMT
Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r097VOIY012087; Wed, 9 Jan 2013 01:31:25 -0600
Received: from [192.168.1.125] (/24.85.226.208) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 08 Jan 2013 23:31:24 -0800
References: <190fcb42a851f2dfe73b2614b7880046@comp.polyu.edu.hk> <CAJV9qO80r93oOk-EjVukF0AUbc5-FWu8VhpVi+9WZBGzSjMrPA@mail.gmail.com> <CABFKGsdJtR3rX+=Puto2D40F9m4kT+rvR6EyU6mx3aEkxG5VNw@mail.gmail.com> <CAJV9qO_A-_5CbfREFBxXr1efaAG5hVdbOR03BNgWY=iBM11fFg@mail.gmail.com> <d2d4bd929ec0d00960e54bd9a3988bf3@comp.polyu.edu.hk> <C932A6E6-3967-4272-99D4-4D10D9A3860B@oracle.com> <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk>
Mime-Version: 1.0 (1.0)
In-Reply-To: <9d620b0a7e3ab7cd272a05a20f88b6b8@comp.polyu.edu.hk>
Content-Type: multipart/alternative; boundary="Apple-Mail-6F7F5350-36D1-4147-B7E1-C30DAD59067C"
Content-Transfer-Encoding: 7bit
Message-Id: <0C41D8C1-FC3E-4635-8911-ECCB6EA62E08@oracle.com>
X-Mailer: iPhone Mail (10A523)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Tue, 08 Jan 2013 23:31:22 -0800
To: cspzhouroc <cspzhouroc@comp.polyu.edu.hk>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: Peng Zhou <zpbrent@gmail.com>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] 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 07:31:35 -0000
The AS is independently authenticating the user and the client in separate steps. Thus it is the AS binding that relation between user and client together ultimately in a scoped access token through a 3-leg process. Phil Sent from my phone. On 2013-01-08, at 23:18, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote: > > > Do you mean the bounding information must be presented by the RO? The client cannot trust the RO-client bounding information that is received from AS? > > > > On Tue, 8 Jan 2013 23:00:03 -0800, Phil Hunt wrote: > >> The idea is to form a bridge between a user, their user-agent, and the client application while at the same time keeping the security credential and the client app cred separate. >> The redirect with code flow enables the separate contexts to be bound together. >> As soon as you do this in one step, then the client app needs to be able to handle the users credentials (eg uid/pwd) directly. Remember that one of the original reasons for the auth flow was to eliminate the password anti-pattern. >> >> Phil >> Sent from my phone. >> >> On 2013-01-08, at 22:52, cspzhouroc <cspzhouroc@comp.polyu.edu.hk> wrote: >> >>> Dear Prabath: >>> >>> >>> >>> But is it possible to include the the mapping between the user request and the code in the message that the AS sends to the client directly? >>> >>> >>> >>> Best Regards >>> >>> Brent >>> >>> >>> >>> On Wed, 9 Jan 2013 12:17:19 +0530, Prabath Siriwardena wrote: >>> >>> >>> >>> On Wed, Jan 9, 2013 at 12:09 PM, Peng Zhou <zpbrent@gmail.com> wrote: >>>> Dear Prabath: >>>> >>>> Thank you very much for your responses :-) >>>> >>>> However, I am still not quite sure why the authorization code must be >>>> sent to the client through the RO's user-agent? >>> One reason I see is, bringing the authorization code via User Agent - links the user request to the authorization code. If AS directly sends the code to the Resource Server the mapping between the user request and the code is broken. >>> Thanks & regards, >>> -Prabath >>> >>>> >>>> Best Regards >>>> Brent >>>> >>>> 2013/1/9 Prabath Siriwardena <prabath@wso2.com>: >>>> > Prabath >>> >>> >>> >>> -- >>> 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-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.