Because that defeats the point of having two different access tokens, one issued with a client secret and the other without. It also requires the JS client to interact a lot more with the server part and wait for responses (no needed when it just sends over the authorization code).
EHL -----Original Message----- From: Marius Scurtescu [mailto:[email protected]] Sent: Tuesday, June 15, 2010 5:24 PM To: Eran Hammer-Lahav Cc: Andrew Arnott; OAuth WG ([email protected]) Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav <[email protected]> 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:[email protected]] > Sent: Tuesday, June 15, 2010 4:19 PM > To: Eran Hammer-Lahav > Cc: Andrew Arnott; OAuth WG ([email protected]) > Subject: Re: [OAUTH-WG] Draft -07 (major rewrite) > > On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
