Subject: [OAUTH-WG] Issue: state in web server flow

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 21:20:09 -0700

Why was the state parameter removed from the web server flow?

Some AS may require the entire redirect URI to be registered, so the state parameter allows a client to maintain state across calls.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 18 Apr 2010 22:28:43 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dick Hardt
> Sent: Sunday, April 18, 2010 9:20 PM
> To: OAuth WG
> Subject: [OAUTH-WG] Issue: state in web server flow
> 

I didn't want to both define a state parameter *and* allow for any other client-specific parameters in redirection URIs. Because people made the point that *any* client-specific parameters are required, I proposed to drop the state parameter. After all, servers MUST send back whatever URI they receive regardless of it being encoded into a state parameter.
 
> Some AS may require the entire redirect URI to be registered, so the state
> parameter allows a client to maintain state across calls.

I agree that this is useful, but it only makes the spec better if we make its use more restrictive. Defining it makes it easier for servers to validate the redirection URI, but only if the client is not allowed using other client-specific query parameters with it.

If people feel strongly about putting it back, I suggest we only allow it with callbacks without any query component as that is the only combination it adds value.

EHL

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Sun, 18 Apr 2010 22:36:02 -0700

> I agree that this is useful, but it only makes the spec better if we make its use more restrictive. Defining it makes it easier for servers to validate the redirection URI, but only if the client i…

Agreed

> If people feel strongly about putting it back, I suggest we only allow it with callbacks without any query component as that is the only combination it adds value.

Agreed

---

From: Evan Gilbert <[email-masked]>
Date: Mon, 19 Apr 2010 07:16:36 -0700

On Sun, Apr 18, 2010 at 10:36 PM, Dick Hardt <[email-masked]> wrote:

> > I didn't want to both define a state parameter *and* allow for any other
> client-specific parameters in redirection URIs. Because people made the
> point that *any* client-specific parameters are required, I proposed to drop
> the state parameter. After all, servers MUST send back whatever URI they
> receive regardless of it being encoded into a state parameter.
> >
> > I agree that this is useful, but it only makes the spec better if we make
> its use more restrictive. Defining it makes it easier for servers to
> validate the redirection URI, but only if the client is not allowed using
> other client-specific query parameters with it.
>
> Agreed
>
> >
> > If people feel strongly about putting it back, I suggest we only allow it
> with callbacks without any query component as that is the only combination
> it adds value.
>
> Agreed
>

Just to verify what is being proposed... is it:

- We will allow callback URIs with query parameters, and
- We will allow client state, but
- We won't allow a callback with client state to a URI with query parameters

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 10:17:38 -0700

>> If people feel strongly about putting it back, I suggest we only allow it with callbacks without any query component as that is the only combination it adds value.

I don't think it is possible to enforce callbacks without any query
parameters. See the Drupal example.

What we can enforce is that the registered callback and the actual
callback have the exact same query parameters.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 11:53:42 -0700

> From: Marius Scurtescu [mailto:[email-masked]]
> Sent: Monday, April 19, 2010 10:18 AM

> I don't think it is possible to enforce callbacks without any query parameters.
> See the Drupal example.

In the Drupal example the client server adds its silly parameters internally. They are not included in what the client provides as its callback URI. 

Can you give an actual callback URI example?

Also, if the client requires query parameters in its callback, it just means it cannot use the client state OAuth parameter.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 13:58:25 -0700

> In the Drupal example the client server adds its silly parameters internally. They are not included in what the client provides as its callback URI.

Silly?

The query parameter may or may not be visible in the registered callback.

> Can you give an actual callback URI example?

http://example.com/oauth2/callback
equivalent with:
http://example.com/index.php?q=oauth2/callback

> Also, if the client requires query parameters in its callback, it just means it cannot use the client state OAuth parameter.

Sure it can, perfectly valid to redirect to:
http://example.com/oauth2/callback?code=123&state=qwerty
which is the same as:
http://example.com/index.php?q=oauth2/callback&code=123&state=qwerty

Justin Richer pointed out that MediaWiki has an identical issue. My
guess is that most PHP frameworks will have this problem.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 19 Apr 2010 14:24:41 -0700

> Sent: Monday, April 19, 2010 1:58 PM
> To: Eran Hammer-Lahav
> Cc: Dick Hardt; OAuth WG
> Subject: Re: [OAUTH-WG] Issue: state in web server flow
> 
> > In the Drupal example the client server adds its silly parameters internally.
> They are not included in what the client provides as its callback URI.
> 
> Silly?

Yes.

> http://example.com/index.php?q=oauth2/callback

Why can't the client always use the first?
 
> > Also, if the client requires query parameters in its callback, it just means it
> cannot use the client state OAuth parameter.
> 

No, I meant according to the last proposal, the state parameter will be limited to cases where there is no query in the callback URI. This makes it easy for servers to validate the pre-registered URI.

EHL

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Apr 2010 16:30:08 -0700

> Why can't the client always use the first?

For the PHP code receiving the callback makes absolutely no
difference, in both cases it sees the second.

The first URL is achieved with Apache doing a rewrite, it acts as a
reverse proxy. The backend code is always called with the query
parameters.

> No, I meant according to the last proposal, the state parameter will be limited to cases where there is no query in the callback URI. This makes it easy for servers to validate the pre-registered U…

Servers can validate pre-registered URIs even of the callback has
query parameters, including strict matching.

Marius