Re: [OAUTH-WG] redircet_uri matching algorithm

David Waite <david@alkaline-solutions.com> Wed, 20 May 2015 17:38 UTC

Return-Path: <david@alkaline-solutions.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 3094E1A89C6 for <oauth@ietfa.amsl.com>; Wed, 20 May 2015 10:38:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.792
X-Spam-Level:
X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 IFQMHl9meO_L for <oauth@ietfa.amsl.com>; Wed, 20 May 2015 10:38:31 -0700 (PDT)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5671A89FA for <oauth@ietf.org>; Wed, 20 May 2015 10:37:38 -0700 (PDT)
Received: from home.alkaline-solutions.com (c-50-155-144-64.hsd1.co.comcast.net [50.155.144.64]) by alkaline-solutions.com (Postfix) with ESMTPSA id A61C7335BF; Wed, 20 May 2015 17:37:35 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2100\))
From: David Waite <david@alkaline-solutions.com>
In-Reply-To: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com>
Date: Wed, 20 May 2015 11:37:33 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D918E17-C0B6-425F-9A1C-F54DC83F730A@alkaline-solutions.com>
References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com>
To: Patrick Gansterer <paroga@paroga.com>
X-Mailer: Apple Mail (2.2100)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/omRg5kT6nY0atjITtf6xUG7ItkI>
Cc: oauth@ietf.org
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 17:38:33 -0000

> 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.

> If not defined the server can choose any supported method, so we do not break existing implementations. On the other side it allows an client to make sure that a server supports a specific matching algorithm required by the client. ATM a client has no possibility to know how a server handles the redirect_uris.

The clients should be more than reasonably safe in assuming exact matching works. If the server won’t support exact matching on the redirect_uris supplied it should fail registration.

-DW