Subject: [OAUTH-WG] state parameter and XSRF detection

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 27 Jun 2011 23:22:28 +0200

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.

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 27 Jun 2011 14:48:40 -0700

On Mon, Jun 27, 2011 at 2:22 PM, Torsten Lodderstedt
<[email-masked]> 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.
>
> "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.
>

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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Shane B Weeden <[email-masked]>
Date: Tue, 28 Jun 2011 09:13:46 +1000

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-masked]>
To:	OAuth WG <[email-masked]>
Date:	28-06-11 07:26 AM
Subject:	[OAUTH-WG] state parameter and XSRF detection
Sent by:	[email-masked]

Hi all,

So this should be fine.

Any comments?

regards,
Torsten.