Re: [OAUTH-WG] redircet_uri matching algorithm

John Bradley <ve7jtb@ve7jtb.com> Thu, 21 May 2015 02:35 UTC

Return-Path: <ve7jtb@ve7jtb.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 F2F1B1ACE88 for <oauth@ietfa.amsl.com>; Wed, 20 May 2015 19:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 bYRoejFf2Xm5 for <oauth@ietfa.amsl.com>; Wed, 20 May 2015 19:35:48 -0700 (PDT)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007681ACE76 for <oauth@ietf.org>; Wed, 20 May 2015 19:35:47 -0700 (PDT)
Received: by qceb3 with SMTP id b3so31627558qce.2 for <oauth@ietf.org>; Wed, 20 May 2015 19:35:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=522JGDw8mij9YRtKE2mRqKdvqXiW9cyiuOQmRifcHwM=; b=LF+lK/T9xei1T8QQIQjk8dVqpAoAXTbR2ZTgETMTzotbN05HqvTeAN9Jmm1um08eym SzzWWxP+Pd8315qbP3hpZXXLdw7VNMO0lF50OCgjWClv1GB8Do43+pzfSfpF6TJDHMmZ M4D1+CHH5zGiHkzNU5T9uVITWMobXUDoz840Y77VTp3I6rwjBoHrByrjAps0sH4zlDO3 D7G+65FDSPXJOCKcZjCHrBgOzzN6E9MjFQNzCE82aSdifQ2qZt/Yme8o7eKZCMu+cE8Y 1e8sVvni+5mhTqZGiELT1ZXHkrRAoxXumCRoSCt76ATm0Qmx6AzDbZkaHFz4sK0M7Jsg KpqQ==
X-Gm-Message-State: ALoCoQnfBp+93Gtub2NR89fXUGqnUaqbKVEKIuLZ606VtkgoHUEhdNXCw1XofKVHg0T2cRDNFmZQ
X-Received: by 10.140.216.83 with SMTP id m80mr623436qhb.14.1432175747175; Wed, 20 May 2015 19:35:47 -0700 (PDT)
Received: from [192.168.8.100] ([181.202.134.151]) by mx.google.com with ESMTPSA id 187sm12340029qhc.39.2015.05.20.19.35.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 May 2015 19:35:46 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com>
Date: Wed, 20 May 2015 23:35:17 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <12863D78-C7CC-4E71-B4F6-09556B8E4F2B@ve7jtb.com>
References: <46886BA8-B8E1-494F-9F5D-4DB6AE0BEB99@paroga.com>
To: Patrick Gansterer <paroga@paroga.com>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/stT6wIa2KtfU0f8XxLgnwbp-XaQ>
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: Thu, 21 May 2015 02:35:50 -0000

I think the correct answer is that clients should always assume exact redirect_uri matching, and servers should always enforce it.  

Anything else is asking for trouble.

If clients need to maintain some state the correct thing to do is use the state parameter, and not append extra path or query elements to there redirect_uri.

A significant number of security problems in the wild come from servers not enforcing this.

I may be taking an excessively hard line, but partial matching is not something we should be encouraging by making easier.

I did do a draft on a way to safely use state https://tools.ietf.org/id/draft-bradley-oauth-jwt-encoded-state-04.txt

John B.


> On May 16, 2015, at 4: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+\\/“]
> 
> 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
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth