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).

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

Reply via email to