On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > It gives you a hybrid solution. The user-agent client doesn't not need to > keep the client secret, but can still move the authorization code to its > server component to obtain a longer lasting refresh token. It also allows the > server to manage the two tokens using different policies (the one obtained > using the user-agent flow directly and the one obtained using an > authenticated client call on the server).
OK, but why cannot this be done with the Web Server profile? The JavaScript client can start the Web Server profile and at the end it gets an authorization code (as a query parameter as opposed to fragment) which it can pass to the its server... Marius > > EHL > > -----Original Message----- > From: Marius Scurtescu [mailto:mscurte...@google.com] > Sent: Tuesday, June 15, 2010 4:19 PM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG (oauth@ietf.org) > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) > > On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <e...@hueniverse.com> > wrote: >> Adding a verification code to the user-agent flow was suggested on >> this list and received nothing but support. It was suggested as a >> solution to a Twitter use case. > > I think it would be good to see a detailed use case where this is really > needed and the previous Web Server and/or User-Agent flows could not do. > > A Java-Script client can use the Web Server flow to grab a verification code > and then either swap it or pass it down to the client server. > > Marius > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
