On Mon, Jun 27, 2011 at 2:22 PM, Torsten Lodderstedt <[email protected]> wrote: > Hi all, > > while working on a new revision of the OAuth security document, a question > arose I would like to clarify on the list. > > The "state" parameter is supposed to be used to link a certain authorization > request and response. Therefore, the client stores a value in this parameter > that is somehow bound to a value retained on the device (the user agent) > originating the authorization request. > > The question now is: Would it be compliant with the core spec to use any > other URI query parameter encoded in the redirect_uri, instead of the > "state" parameter, to achieve the same goal? Probably the client already has > a working "legacy" implementation it does not want to change just for OAuth2 > compliance. > > According to section 2.2.1, the redirection uri could contain a dynamic > portion: > > "The authorization server SHOULD require the client to pre-register > their redirection URI or at least certain components such as the > scheme, host, port and path" > > So this should be fine. > > Any comments?
It all depends on the authorization server. For example, currently Google does strict matching on the redirect URI, so you must use "state". I think "state" is the only safe, portable option. Unless the OAuth 2 spec dictates how URI matching should be done. Marius > > regards, > Torsten. > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
