On Wed, May 26, 2010 at 8:51 PM, Evan Gilbert <[email protected]> wrote:
> > > On Tue, May 25, 2010 at 1:43 PM, Murali VP <[email protected]> wrote: > >> Anyway to find out what the outcome was from the May 20th interim meeting? >> I >> wanted to participate but had to be at Google I/O. >> >> 3.5. User-Agent Flow >> >> 1. Since the client_id is public, the only check that prevents from >> any client posing as a registered client is the redirect_uri, this is >> fine, except that if client web application has numerous domains, each >> domain should register and have a separate client_id which is a pain. >> The alternative of a single redirect_uri returning a 302 won't work >> since the fragment will no more be available (I guess there are ways >> to get around this). >> > > You can have a single redirect_uri that does a client side redirect using > JavaScript. The only catch is that this is dangerous from a security > perspective - your additional redirect needs to have strict rules about the > domains it can forward to - so this should be considered a power-developer > technique and we need to write up best practices or better provide a JS > library that has gone through review. > > Agree with you, based on the fact that the access_token is sent in the fragment and not as a query parameter attached to the redirect_uri implies that the access_token is not meant to be sent to the client's web server, so the forwarding cannot result in sending the access_token but should continue to attach the fragment which the forwarded to domain should still have a script to read and use the access_token in the fragment.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
