Re: [OAUTH-WG] OAuth 2.0 Discovery Location

George Fletcher <gffletch@aol.com> Thu, 25 February 2016 15:14 UTC

Return-Path: <gffletch@aol.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A181B2A12 for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4cc2dxiiYEI for <oauth@ietfa.amsl.com>; Thu, 25 Feb 2016 07:14:07 -0800 (PST)
Received: from omr-a018e.mx.aol.com (omr-a018e.mx.aol.com [204.29.186.64]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CC121B2A1A for <oauth@ietf.org>; Thu, 25 Feb 2016 07:14:07 -0800 (PST)
Received: from mtaout-aad02.mx.aol.com (mtaout-aad02.mx.aol.com [172.26.127.226]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 4BFA63800336; Thu, 25 Feb 2016 10:14:06 -0500 (EST)
Received: from [10.172.228.63] (unknown [10.172.228.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aad02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2E15E3800008D; Thu, 25 Feb 2016 10:14:03 -0500 (EST)
To: "Manger, James" <James.H.Manger@team.telstra.com>, "<oauth@ietf.org>" <oauth@ietf.org>
References: <E3BDAD5F-6DE2-4FB9-AEC0-4EE2D2BF8AC8@mit.edu> <CAEayHEMspPw3pu9+ZudkMp9pBPy2YYkiXfPvFpSwqZDVyixWxQ@mail.gmail.com> <CABzCy2CpSB2Nrs-QoaEwpqtG4J8UNeAYNy1rion=mp5PQD2dmg@mail.gmail.com> <FE60D9CC-0457-4BDB-BCF1-461B30BF0CDE@oracle.com> <56CE01B1.7060501@aol.com> <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <56CF1A45.6040708@aol.com>
Date: Thu, 25 Feb 2016 10:14:13 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BBB0194A6@WSMSG3153V.srv.dir.telstra.com>
Content-Type: multipart/alternative; boundary="------------030206080706040602040701"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456413246; bh=HdJRpY++Nmhhx8/T0j14Ef/fR78R7dfyh1ByQzBSJ4Q=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=IMf072lqd6enRJ+/9HRB/WTww77vS54c7Hbo2ICGsMEBaI3i4qzr/6KuhVZhdp6Nx 9xkY6cWWZ3gVIYOFkGUcqQqm/vUC6iBeJ0+0BpUgMmj71t7tIrHMeBCm6XisoSbfG+ H6RXeZXlJymx7Rs54RAj4rvnGOkPq6T2RUZlgNFk=
x-aol-sid: 3039ac1a7fe256cf1a3b047d
X-AOL-IP: 10.172.228.63
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Cx6CEe-yVlpQF43F1SQQJmkya08>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 25 Feb 2016 15:14:14 -0000

The AS knows the RS's that will consume it's tokens because it knows the 
scopes that it can allow the user to authorize. I don't think the AS 
MUST know the endpoints of the RS (which is what the current drafts 
require).

It is not often that the entity/group responsible for the Authorization 
Service is also responsible for the actual resource server. Take for 
example a Mail API run by one team and the Authorization server managed 
by the Identity team.

Requiring the Mail Team to notify and coordinate the change of endpoints 
for a new deployment is brittle.

Also, I believe the main reason for wanting to bind a token to an 
endpoint is to protect the token from being sent to a malicious RS and 
then having that RS replay the token. If possible replay of a token is 
the main concern, then why not use PoP which ensures that only the 
appropriate client and present the token. This seems a much cleaner way 
to protect against this threat.

Thanks,
George

On 2/25/16 2:02 AM, Manger, James wrote:
>
> > I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture
>
> The AS is issuing temporary credentials (access_tokens) to clients but 
> doesn’t know where those credentials will work? That’s broken.
>
> An AS should absolutely indicate where an access_token can be used. 
> draft-sakimura-oauth-meta suggests indicating this with 1 or more 
> “ruri” (resource URI) values in an HTTP Link header. A better approach 
> would be including a list of web origins in the token response beside 
> the access_token field.
>
> --
>
> James Manger
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *George 
> Fletcher
> *Sent:* Thursday, 25 February 2016 6:17 AM
> *To:* Phil Hunt <phil.hunt@oracle.com>om>; Nat Sakimura <sakimura@gmail.com>
> *Cc:* <oauth@ietf.org> <oauth@ietf.org>
> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Discovery Location
>
> I'm concerned that forcing the AS to know about all RS's endpoints 
> that will accept it's tokens creates a very brittle deployment 
> architecture. What if a RS moves to a new endpoint? All clients would 
> be required to get new tokens (if I understand correctly). And the RS 
> move would have to coordinate with the AS to make sure all the timing 
> is perfect in the switch over of endpoints.
>
> I suspect a common deployment architecture today is that each RS 
> requires one or more scopes to access it's resources. The client then 
> asks the user to authorize a token with a requested list of scopes. 
> The client can then send the token to the appropriate RS endpoint. The 
> RS will not authorize access unless the token has the required scopes.
>
> If the concern is that the client may accidentally send the token to a 
> "bad" RS which will then replay the token, then I'd rather use a PoP 
> mechanism because the point is that you want to ensure the correct 
> client is presenting the token. Trying to ensure the client doesn't 
> send the token to the wrong endpoint seems fraught with problems.
>
> Thanks,
> George
>