[OAUTH-WG] redircet_uri matching algorithm

Patrick Gansterer <paroga@paroga.com> Sat, 16 May 2015 07:43 UTC

Return-Path: <paroga@paroga.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 143721AD05D for <oauth@ietfa.amsl.com>; Sat, 16 May 2015 00:43:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] 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 o09Bf7CY-X9N for <oauth@ietfa.amsl.com>; Sat, 16 May 2015 00:43:27 -0700 (PDT)
Received: from mail.dynms.de (mail.dynms.de [85.25.184.156]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973651ACF1C for <oauth@ietf.org>; Sat, 16 May 2015 00:43:27 -0700 (PDT)
Received: from [10.10.10.101] (chello084112032036.1.11.vie.surfer.at [84.112.32.36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.dynms.de (Postfix) with ESMTPSA id 4CAC05461F16 for <oauth@ietf.org>; Sat, 16 May 2015 09:43:23 +0200 (CEST)
From: Patrick Gansterer <paroga@paroga.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com>
Date: Sat, 16 May 2015 09:43:23 +0200
To: oauth@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/lv13yOGaKOCE8byjDGdSSHFRczc>
X-Mailman-Approved-At: Wed, 20 May 2015 09:01:41 -0700
Subject: [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: Sat, 16 May 2015 07:43:29 -0000

"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+\\/“]

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.

[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29
[2] http://www.ietf.org/mail-archive/web/oauth/current/msg02617.html

--
Patrick Gansterer