Re: [OAUTH-WG] redircet_uri matching algorithm

Bill Burke <bburke@redhat.com> Wed, 20 May 2015 18:00 UTC

Return-Path: <bburke@redhat.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 B55E11A8A09 for <oauth@ietfa.amsl.com>; Wed, 20 May 2015 11:00:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5r7qqRX5jPed for <oauth@ietfa.amsl.com>; Wed, 20 May 2015 11:00:28 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014911A8942 for <oauth@ietf.org>; Wed, 20 May 2015 11:00:23 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4KI0M9B028827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <oauth@ietf.org>; Wed, 20 May 2015 14:00:22 -0400
Received: from [10.10.57.144] (vpn-57-144.rdu2.redhat.com [10.10.57.144]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4KI0KdC021456 for <oauth@ietf.org>; Wed, 20 May 2015 14:00:21 -0400
Message-ID: <555CCBB5.3000607@redhat.com>
Date: Wed, 20 May 2015 14:00:21 -0400
From: Bill Burke <bburke@redhat.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: oauth@ietf.org
References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com> <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com>
In-Reply-To: <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Buqwi-YoBBSVChA5cQmSPdNXbtk>
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm
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: <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, 20 May 2015 18:00:29 -0000


On 5/20/2015 1:37 PM, David Waite wrote:
>
>> On May 16, 2015, at 1:43 AM, Patrick Gansterer <paroga@paroga.com> wrote:
>>
>> "OAuth 2.0 Dynamic Client Registration Protocol” [1] is nearly finished and provides the possibility to register additional “Client Metadata”.
>>
>> OAuth 2.0 does not define any matching algorithm for the redirect_uris. The latest information on that topic I could find is [1], which is 5 years old. Is there any more recent discussion about it?
>>
>> I’d suggest to add an OPTIONAL “redirect_uris_matching_method” client metadata. Possible valid values could be:
>> * “exact”: The “redirect_uri" provided in a redirect-based flow must match exactly one of of the provided strings in the “redirect_uris” array.
>> * “prefix”: The "redirect_uri" must begin with one of the “redirect_uris”. (e.g. "http://example.com/path/subpath” would be valid with [“http://example.com/path/“, “http://example.com/otherpath/”])
>> * “regex”: The provided “redirect_uris” are threatened as regular expressions, which the “redirect_uri” will be matched against. (e.g. “http://subdomain.example.com/path5/“ would be valid with [“^http:\\/\\/[a-z]+\\.example\\.com\\/path\\d+\\/“]
>
> I don’t know if this is appropriate. For example, If a server is unwilling to support arbitrary regex matching, how would a client which required this be able to register dynamically? Or conversely: if a client did not require regex matching, why would they request this from a server?
>
> If a client requests regex or prefix, it was built to rely on these to work. If some set of servers choose not to support regex or prefix for scope or security reasons, this hurts interoperability from the perspective of dynamic registration. And we already have a workaround - instead make your client rely on the state parameter.
>
> A client doing code or implicit should specify exact return URLs in their registration, and if they need to send the user someplace else after authentication it should be represented to the client by their state param.
>

Nice workaround, but you are then making the client more difficult to 
implement and the state param larger and more complex.  prefix matching 
seems like it would be a very common thing that an auth server supports 
and clients would want to have.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com