I think somewhere in here my original comments got lost. The spec, as written, provides no limitations on what can go in the state variable. If we don't define those limitations in the spec implementors are going to define their own limitations (I'm on the verge of doing it myself).
I propose that the state variable be limited to the set of characters [a-zA-Z0-9_-] and be restricted to a maximum length of 150 characters. It's simple, doesn't require URL encoding, and will be hard for a client application to turn into a vulnerability. It provides plenty of uniqueness (it can fit a sha512) for even the largest and most used client applications. -Bob On Wed, Jul 20, 2011 at 8:24 AM, Breno <breno.demedei...@gmail.com> wrote: > > > On Mon, Jul 18, 2011 at 11:32 PM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> >> >> > -----Original Message----- >> > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf >> > Of Eliot Lear >> > Sent: Sunday, July 17, 2011 2:49 AM >> >> > One other point: if the redirection_uri can have fragments and can be >> > provided, why is state necessary? >> >> First, I assume you mean query instead of fragment. >> >> This was discussed on the list about a year ago. There isn't a requirement >> to support both dynamic redirection URIs as well as a special state >> parameter. However, the state parameter provides a better way to allow >> customization of the redirection request alongside full registration of the >> redirection URI. Section 3.1.2 recommends using the state parameter over >> changing the redirection URI itself. >> >> Using state is much simpler because the authorization server does not have >> to implement potentially insecure URI comparison algorithms for dynamic >> redirection URIs. > > Agree -- for instance, Google's provider doesn't allow arbitrary dynamic > specification of query or fragment parameters in redirect URIs, for > instance, due largely to security considerations. > >> >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Breno de Medeiros > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
