Re: [OAUTH-WG] Variant of Web Server Flow w/o direct communication

[Torsten Lodderstedt <[e-mail]>]

Am 22.04.2010 02:23, schrieb Evan Gilbert:
>
>>
>>     At one point we had tokens in query string for the User-Agent
>>     flow, but there were concerns about the security side. Query
>>     parameters are much more likely to leak in logs and in referrers.
>>
>>     It's not a lot of work to support this functionality with the
>>     existing User-Agent flow using a boilerplate response page. Page
>>     would:
>>     1. Grab fragment
>>     2. Make XMLHttpRequest with access token & refresh token to
>>     server, or POST a form
>>     3. Redirect to destination page.
>>
>>     Would this work?
>
>     I think this would work but is IMHO somehow cumbersome and
>     requires two requests to the service.
>
>
> I agree it's cumbersome. Hopefully the security folks can respond with 
> the pros/cons of tokens in the query parameters.

I dicussed security considerations in my proposal. Depending on the risk 
assessment of the application/deployment, one will need to sign the 
request or encrypt the response.

>     Alternatively, the authorization server could directly respond
>     with a HTML page containing a HTML form element with all response
>     data. This form could automatically be submited to the service
>     using JavaScript. This would be similar to OpenIds "HTML FORM
>     Redirection".
>
>
> This is a good idea. Might make sense to support as a best practice - 
> the form can be static and it's fairly easy for any client to host it.
>
> We recently had a similar discussion on the Native Application flow on 
> the OAuth WG thread - decided that we could implement the Native Flow 
> as the Web Server flow + a simple HTML web page. And the web page 
> wouldn't be directly part of the spec, but a separately documented 
> best practice.
>
> (note - I don't have strong opinions on this - mostly discussing options)

I don't know whether the flow can really be implemented w/o standard 
support.

1) The server has to decide when to respond with conventional redirect 
and when with  HTML FORM Redirection. This could probably be setup on a 
per client base.
2) The client may not perform the second call in order to retrieve the 
tokens. Instead it shall use the response parameters. I don't expect 
libraries to support this behavior as long as the standard does not 
specifies it.

regards,
Torsten.

>
>
>     regards,
>     Torsten.
>
>