Re: [OAUTH-WG] OAuth 2.0 Discovery Location
George Fletcher <gffletch@aol.com> Wed, 24 February 2016 19:17 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 02E161B3CE3 for <oauth@ietfa.amsl.com>; Wed, 24 Feb 2016 11:17:04 -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 xGl4ESwR5xQq for <oauth@ietfa.amsl.com>; Wed, 24 Feb 2016 11:17:00 -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 65C371B3C8C for <oauth@ietf.org>; Wed, 24 Feb 2016 11:17:00 -0800 (PST)
Received: from mtaout-aal02.mx.aol.com (mtaout-aal02.mx.aol.com [172.27.20.206]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 4CF6B3800065; Wed, 24 Feb 2016 14:16:59 -0500 (EST)
Received: from [10.172.102.179] (unknown [10.172.102.179]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aal02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id AB80F38000091; Wed, 24 Feb 2016 14:16:58 -0500 (EST)
To: Phil Hunt <phil.hunt@oracle.com>, Nat Sakimura <sakimura@gmail.com>
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>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <56CE01B1.7060501@aol.com>
Date: Wed, 24 Feb 2016 14:17:05 -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: <FE60D9CC-0457-4BDB-BCF1-461B30BF0CDE@oracle.com>
Content-Type: multipart/alternative; boundary="------------090508070402050108000503"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1456341419; bh=dwPEs9GPaVOU31R0Ztz7yTYRfFCPXljYZhB0AQUQ/3A=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=pplehTuP0zfdCijwmU5bNNWJ2DYfdLdauNjlxtiXKiWQPSLZteqyir/U2SqWLcVvN NvMsJx0vIzDEYDWULfAy6Q+IcFqv7YLLeBn3XO1nN5d+uGqSaL9G5ICBM60sbFHfjB zKdaML7eJ56B3VH4+dD+gPuGezQekp44fb8zCkZU=
x-aol-sid: 3039ac1b14ce56ce01aa43ec
X-AOL-IP: 10.172.102.179
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/pNvcMBg8pOhB67w8Sr5FGIrHe2o>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
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: Wed, 24 Feb 2016 19:17:04 -0000
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 On 2/24/16 9:59 AM, Phil Hunt wrote: > Nat, > > I’m not sure that having the resource server tell the client where its > authorization server is secure by itself. The relationship between the > Authorization Server and the Resource server need to be bound together > in one of the discovery endpoints (the resource and/or the oauth > service discovery). > > If a client discovers a fake resource server that is proxying for a > real resource server the current discovery spec will not lead the > client to understand it has the wrong resource server. Rather the fake > resource service will just have a fake discovery service. The hacker > can now intercept resource payload as well as tokens because they were > able to convince the client to use the legit authorization service but > use the token against the hackers proxy. > > The OAuth Discovery service needs to confirm to the client that the > server is able to issue tokens for a stated resource endpoint. > > This not only works in normal OAuth but should add security even to > UMA situations. > > Phil > > @independentid > www.independentid.com <http://www.independentid.com> > phil.hunt@oracle.com <mailto:phil.hunt@oracle.com> > > > > > >> On Feb 24, 2016, at 3:54 AM, Nat Sakimura <sakimura@gmail.com >> <mailto:sakimura@gmail.com>> wrote: >> >> >> Hi Thomas, >> >> inline: >> >> 2016年2月22日(月) 18:44 Thomas Broyer <t.broyer@gmail.com >> <mailto:t.broyer@gmail.com>>: >> >> Couldn't the document only describe the metadata? >> I quite like the idea of draft-sakimura-oauth-meta if you really >> want to do discovery, and leave it open to implementers / to >> other specs to define a .well-known URL for "auto-configuration". >> The metadata described here would then either be used as-is, at >> any URL, returned as draft-sakimura-oauth-meta metadata at the >> RS; or as a basis for other metadata specs (like OpenID Connect). >> >> With draft-sakimura-oauth-meta's "duri" and the "scope" attribute >> of WWW-Authenticate response header, you have everything you need >> to proceed >> >> >> Yup. That's one of the requirements to be RESTful, is it not? >> >> In OAuth's case, the resource and the authorization server are >> usually tightly coupled. (Otherwise, you need another specs like UMA.) >> So, the resource server should be able to tell either the location of >> the authz endpoint. In some trusted environment, the resource may as >> well return the location of the authz server configuration data. In >> these cases, you do not have to decide on what .well-known uri as you >> say. This frees up developers from configuration file location >> collisions etc. We should strive not to pollute the uri space as much >> as possible. >> >> (well, except if there are several ASs each with different >> scopes; sounds like an edge-case to me though; maybe RFC6750 >> should instead be updated with such a parameter such that an RS >> could return several WWW-Authenticate: Bearer, each with its own >> "scope" and "duri" value?) >> >> >> Yeah, I guess it is an edge case. I would rather like to see these >> authz servers to develop a trust framework under which they can agree >> on a single set of common scope parameter values. >> >> Cheers, >> >> Nat >> >> >> >> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu >> <mailto:jricher@mit.edu>> wrote: >> >> The newly-trimmed OAuth Discovery document is helpful and >> moving in the right direction. It does, however, still have >> too many vestiges of its OpenID Connect origins. One issue in >> particular still really bothers me: the use of >> “/.well-known/openid-configuration” in the discovery portion. >> Is this an OAuth discovery document, or an OpenID Connect >> one? There is absolutely no compelling reason to tie the URL >> to the OIDC discovery mechanism. >> >> I propose that we use >> “/.well-known/oauth-authorization-server” as the default >> discovery location, and state that the document MAY also be >> reachable from “/.well-known/openid-configuration” if the >> server also provides OpenID Connect on the same domain. Other >> applications SHOULD use the same parameter names to describe >> OAuth endpoints and functions inside their service-specific >> discovery document. >> >> — Justin >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography
- [OAUTH-WG] OAuth 2.0 Discovery Location Justin Richer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- [OAUTH-WG] OAuth 2.0 Discovery Location Samuel Erdtman
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Samuel Erdtman
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Justin Richer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Anthony Nadalin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Anthony Nadalin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt (IDM)
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Manger, James
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Donald F. Coffin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Donald F. Coffin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Donald F. Coffin
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location John Bradley
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Manger, James
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Nat Sakimura
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location nov matake
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location John Bradley
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Justin Richer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location torsten@lodderstedt.net
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Samuel Erdtman
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Phil Hunt
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Mike Jones
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Brian Campbell
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Brian Campbell
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Roland Hedberg
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location Thomas Broyer
- Re: [OAUTH-WG] OAuth 2.0 Discovery Location George Fletcher