Sounds reasonable - subject to the content of the validation rules for a registered redirect URI (section 10.11 TBD). The security considerations doc (or section 10.13 of the spec itself which is TBD) should make it clear that the state parameter must be provided by the client to prevent CSRF against the redirect_uri unless the client is already using another dynamically parameter in the redirect_uri for that purpose. Text should also include some recommendation on state parameter entropy, along with describing how it should be validated when the redirect_uri is accessed.
Regards, Shane. From: Torsten Lodderstedt <[email protected]> To: OAuth WG <[email protected]> Date: 28-06-11 07:26 AM Subject: [OAUTH-WG] state parameter and XSRF detection Sent by: [email protected] 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? 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
