[Openid-specs-ab] Question to Google about redirect_uri parameter in authorization request

Tim Bray tbray at textuality.com
Fri Dec 7 15:57:18 UTC 2012


For the record, I disagree; It is *extremely* bad practice for an RP to
leave out the redirect_uri, increasing the likelihood that your setup will
suddenly break one morning because of an unrelated server-side config
change.  Altering the spec to allow this misbehavior weakens the
interoperability of the standard.

But I guess I’m in the minority here.  -Tim

On Thu, Dec 6, 2012 at 9:44 PM, Mike Jones <Michael.Jones at microsoft.com>wrote:

>  OK – for the purposes of the pending update spec release, I’m going to
> update the specs to be internally consistent and require clients to send
> the redirect_uri value.  But I’ll also make it clear that servers may
> choose not to trigger an error when a request is received without a
> redirect_uri and there is exactly one registered redirect_uri value.
> (Credit to John Bradley for this idea.)  That way, conforming clients will
> always send it but servers that are looser with this behavior for other
> OAuth requests can continue to be loose in that way with OpenID Connect
> requests as well.****
>
> ** **
>
> Thanks all for the good discussion.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Brian Campbell [mailto:bcampbell at pingidentity.com]
> *Sent:* Thursday, December 06, 2012 2:19 PM
> *To:* Mike Jones
> *Cc:* Breno de Medeiros; <openid-specs-ab at lists.openid.net>; Naveen
> Agarwal
> *Subject:* Re: [Openid-specs-ab] Question to Google about redirect_uri
> parameter in authorization request****
>
> ** **
>
> Sorry for the slow response. Responses inline.****
>
> ** **
>
> On Wed, Dec 5, 2012 at 5:50 PM, Mike Jones <Michael.Jones at microsoft.com>
> wrote:****
>
> Brian, is the current inconsistency within the Connect specs that you've
> identified in this sentence in
> http://openid.net/specs/openid-connect-standard-1_0.html#anchor9: "Ensure
> that the redirect_uri parameter is present if the redirect_uri parameter
> was included in the initial Authorization Request and that their values are
> identical for the Scheme, Host, Path, and Query Parameter segments"?  If
> the phrase "if the redirect_uri parameter was included in the initial
> Authorization Request" were deleted, would the Connect specs then be
> self-consistent, in your view?
>  ****
>
>
> As far as it's requiredness on the authorization and token requests, I
> think that would do it (with a little wordsmithing on that statement
> anyway).   Looking at all the places I referenced in the ticket, I thought
> it was a mistake and I guess I was really expecting it would be changed to
> optional. *Sigh*
>
>  ****
>
> Or are you also concerned that this language in
> http://openid.net/specs/openid-connect-registration-1_0.html#anchor3would be inconsistent: "redirect_uris - RECOMMENDED for Clients using the
> code flow with a query parameter encoded response. REQUIRED for Clients
> requesting implicit flow fragment encoded responses as defined in OAuth 2.0
> [OAuth2.0]. A space-delimited list of redirect URIs. One of the URL MUST
> match the Scheme, Host, and Path segments of the redirect_uri in the
> authorization request."?  Or do people also believe that registering
> redirect_uris should always be REQUIRED?****
>
>
> I don't know the reasoning for having it that way so can't really comment
> on if registering redirect_uris should always be required. It is maybe a
> little awkward that it's sort of optional there in registration but text
> like "The Scheme, Host, Path, and Query Parameter segments of this URI MUST
> match one of the redirect_uris registered for the client_id in the OpenID
> Connect Dynamic Client Registration 1.0<http://openid.net/specs/openid-connect-standard-1_0.html#OpenID.Registration>[OpenID.Registration] specification." from
> http://openid.net/specs/openid-connect-standard-1_0.html#rf_prep sort of
> read as though a client will always have uris registered.  That text also
> could potentially be interpreted as a hard dependency of standard on
> dynamic registration but maybe I'm being too nit-picky...
>
>  ****
>
>                                 Thanks all,
>                                 -- Mike****
>
> ** **
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121207/b4f1c681/attachment-0001.html>


More information about the Openid-specs-ab mailing list