> On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb <oleg_g...@yahoo.com> wrote:
> > Returning to our discussion about necessity of passing access_token in
>URL's
> > fragment, I've read both your proposal for changing v.9 and the current
> > v.10, but still don't understand why we need access_token in a fragment.
>
> Question: why are you implementing the user-agent flow?
It's not helpful. Doesn't answer the qs.
> > I think, a safer solution would be to return an access token in a response
> > form, not in Location header. This way, we'll avoid problems with user
> > agents that David Stanek described and prevent browsers from storing tokens
> > in a browser's history.
>
> This is nuts.
That's what I thought when was reading User Agent Flow in v.10, but I didn't
voice it, because wanted to be polite to the authors. My opinion didn't change
much after this discussion, but it probably will, after I get my answers (see
below).
>It would completely break all of the use cases the
> user-agent flow was designed to address.
> For example, let's say you want to allow third-party site
> thirdparty.com to embed some javascript from serviceprovider.com.
>
Please provide an example of code that you would put to thirdparty.com and that
would not break the use cases. Please also provide an example of response from
serviceprovider.com with an access token in it (wherever it is - as I
understand
you want to put it to the Location header, but probably I'm wrong).
> - do all of the above without server-side code at thirdparty.com.
Is it a requirement/use case? Where is it written in the spec? What if
thirdparty.com generates that JavaScript on the server and returns in a
response? Would it be a violation of the protocol? If it would, do you want to
require only static content containing that script at thirdparty.com?
> - do all of the above with as few client <-> server round trips as possible.
When it comes to an authentication and communication protocols, security is
more
important than an extra round trip in my view, otherwise people would never use
SSL, which is very inefficient from performance point of view. Also, until I
see
the code that I've asked for above, I won't understand how that "fragment"
solution will reduce the number of trips.
We can see from this discussion so far that:
1. You don't know how many user agents are out there that would send the
fragment with the token in a request.
2. It's not clear if that "replace" function will be sufficient to clear
browser's history in numerous browsers and their versions.
These are still valid security concerns.
Best,
Oleg.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
