Re: [OAUTH-WG] redircet_uri matching algorithm

Justin Richer <> Wed, 20 May 2015 18:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C063A1A8A85 for <>; Wed, 20 May 2015 11:44:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f1yEJyh4Cf2R for <>; Wed, 20 May 2015 11:43:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 33E0E1A8A89 for <>; Wed, 20 May 2015 11:43:59 -0700 (PDT)
X-AuditID: 1209190e-f79a76d000000d1b-06-555cd5ed1123
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F2.AB.03355.DE5DC555; Wed, 20 May 2015 14:43:57 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id t4KIhvbU029845; Wed, 20 May 2015 14:43:57 -0400
Received: from artemisia.richer.local ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id t4KIhs2b024842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 May 2015 14:43:56 -0400
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_ADB759CC-D860-46FA-B5D6-09EE6B868C84"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail 2.5b6
From: Justin Richer <>
In-Reply-To: <>
Date: Wed, 20 May 2015 14:43:54 -0400
Message-Id: <>
References: <> <> <>
To: Bill Burke <>
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLKsWRmVeSWpSXmKPExsUixCmqrfv2akyowf0lxha9W3cyWpx8+4rN gcljyZKfTB7v911lC2CK4rJJSc3JLEst0rdL4MrY9e4eS8F+lYptHR9YGhj/ynUxcnJICJhI LD//khnCFpO4cG89G4gtJLCYSWL2UZ4uRi4geyOjxOFvjcwQzkMmiWszrrOCVAkLmEucedLK DmLzChhIzD31hQmkiFlgCqPExzmr2CDGSkk0vT7GCGKzCahKTF/TwgRicwpoSdzo3Q82iAUo vuz/bSCbA6hZXaL9pAvETCuJrTdOs0Msnskocf3oDLBlIgJKEqt+TmADqZcQkJfo2ZQ+gVFw FpIzZiE7AyTBLKAtsWzha2YIW1Nif/dyFghbXmL72zlQcUuJxTNvQMVtJW71LWCCsO0kHk1b xLqAkWMVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK6SZGcOxI8u1g/HpQ6RCjAAej Eg9vwYHoUCHWxLLiytxDjJIcTEqivBcvxYQK8SXlp1RmJBZnxBeV5qQWH2JUAdr1aMPqC4xS LHn5ealKIrzn1gPV8aYkVlalFuXDlElzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4L19 BahRsCg1PbUiLTOnBCHNxMF5iFGCgwdo+GaQGt7igsTc4sx0iPwpRl2OHTd/L2ISArtASpz3 PUiRAEhRRmke3BxYKnzFKA70ojDvVJAqHmAahZv0CmgJE9ASk22RIEtKEhFSUg2MklYSflYF LqGZzfN1Fv1L9utltfmyN8BZcu9D4fcr/j0tuufPsv2f8v40h+4NcZOln9xIe6P/0P7Q7DPH s+dvuvBAXfnlZ23urxLB1qfz32QGsbo75Yixm66rlourPJFQuEpfnCM6SVjTwPtg5ftuLe8T K48VsxxzETu8Qv6GrsY25y2p6QlKLMUZiYZazEXFiQCJgvA2YAMAAA==
Archived-At: <>
Cc: "<>" <>
Subject: Re: [OAUTH-WG] redircet_uri matching algorithm
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 May 2015 18:44:01 -0000

You don’t have to encode the parameters into the state parameter, just have them be referenceable *from* the state parameter, so it’s complexity doesn’t change. What I’ve seen done in several implementations (including our own) is that you generate a random State value, then save that into the session, along with any other stateful information like an ultimate target URI or other parameters. When the request comes back, I look back inside the session object to see if the state value matches what I’d stored earlier. If so, I can get out all the rest of the stuff that we stored before the auth request.

 — Justin

> On May 20, 2015, at 2:00 PM, Bill Burke <> wrote:
> On 5/20/2015 1:37 PM, David Waite wrote:
>>> On May 16, 2015, at 1:43 AM, Patrick Gansterer <> 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. "” would be valid with [““, “”])
>>> * “regex”: The provided “redirect_uris” are threatened as regular expressions, which the “redirect_uri” will be matched against. (e.g. ““ 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
> _______________________________________________
> OAuth mailing list