On Wed, Jun 15, 2011 at 6:09 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > >> -----Original Message----- >> From: Shane B Weeden [mailto:swee...@au1.ibm.com] >> Sent: Wednesday, June 15, 2011 3:19 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Redirection URI and Implicit grant >> >> > From: Eran Hammer-Lahav <e...@hueniverse.com> >> > To: OAuth WG <oauth@ietf.org> >> > Date: 16-06-11 05:43 AM >> > Subject: [OAUTH-WG] Redirection URI and Implicit grant Sent by: >> > oauth-boun...@ietf.org >> > >> > This is coming from recent experience building a full web service and >> > multiple clients using OAuth 2.0. I am going to make these changes to >> > my own implementation and would like to raise the questions here and >> > discuss possible changes. >> > >> > A few questions: >> > >> > 1. Why not require the registration of a redirection URI for implicit >> > grant requests, removing the redirect_uri parameter completely from >> > the request (the client can still use the state >> parameter)? >> >> I can imagine situations where one-or-more redirect URI's may be required >> rather than a single explicit URI. I think that either a >> child-urlpath-of-the- >> registered URI, and/or the ability to register multiple valid URI's for a >> particular client id allows this without being overly restrictive. >> > > Then just use multiple client identifiers if you need multiple redirection > URIs, or better yet, use the state parameter and route the request on the > client side based on the state value.
If you allow localhost or non-routable IP addresses in the redirect URI this is not possible. > Authorization server who want to be fancy can allow you to register more than > one and let you indicate which one you want by adding a suffix to the client > id (say 'abcd-1' to pick URI 1). What Brian said. Plus, this is extremely fragile and confusing, as soon as the client edits its registration information the order may change. Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth