Subject: Re: [OAUTH-WG] Proposal: make it possible to get a verification code in the user-agent flow

From: Chuck Mortimore <[email-masked]>
Date: Thu, 10 Jun 2010 16:00:42 -0700

Did anyone ever write up the specifics of this?   I've seen general support, and would like to see it added.

-cmort

On 5/24/10 2:22 PM, "Eran Hammer-Lahav" <[email-masked]> wrote:

Anyone wants to turn this into an actual proposal with list of changes to the current flow?

EHL

On 5/23/10 7:13 PM, "Luke Shepard" <[email-masked]> wrote:

Brian - I like your proposal. It solves the refresh token problem and the server-side auth in one go.

Marius - your proposal would work great in a circumstance where you have strong integration between JavaScript and the server, and they are both controlled by the same developer. In that case, sure, the developer could pass the access token back to the front-end (although you would have a perf hit).

However, the case that I'd like to solve (and what I read, Brian wants to as well) is like this:

- Client includes some Javascript from the relevant service (either Facebook or Twitter @anywhere)
- The JS handles the auth flow and does some client-side API calls - for example, Twitter displays hovercards on each username on the site, or Facebook renders some profile pics
- The JS also passes a token down to the server - either in the cookies, or perhaps directly via an Ajax call
- The server can now independently make its own API calls if it wants, and gets a refresh token or whatever else it wants

This allows for a single, general purpose JS library that handles auth for both client and server applications - which is something that the web server flow by itself does not allow.

On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote:

> On Fri, May 21, 2010 at 1:46 PM, Brian Ellin <[email-masked]> wrote:
>> Marius,
>> I don't understand.  Will you elaborate on how specifically that would work?
>
> Maybe I am missing something, but I was suggesting that the JavaScript
> code starts a web server flow at the end of which it has a
> verification code. It passes this verification code down to the client
> server, the client server swaps it for an access token and a refresh
> token and passes the access token to the JavaScript client. When the
> access token expires the client JavaScript has two options, ask the
> client server for a refresh or do an immediate request to that authz
> server.
>
> If you want that the client server and client JavaScript have tokens
> with totally different scopes, then you probably want to send the user
> for approval twice. If you just want the client JavaScript to have a
> token with a lesser scope (and avoid a second approval), then we
> should probably look into down-scoping, which currently is not
> supported.
>
> Would that work?
>
> Marius
>
>
>> Brian
>>
>> On Fri, May 21, 2010 at 12:35 PM, Marius Scurtescu <[email-masked]>
>> wrote:
>>>
>>> Why not use the web server flow in this case?
>>>
>>> I think it should work with un-registered clients as well (no client
>>> secret).
>>>
>>> Marius
>>>
>>>
>>>
>>> On Fri, May 21, 2010 at 10:39 AM, Brian Ellin <[email-masked]> wrote:
>>>> We're using the OAuth 2.0 User-Agent flow in @anywhere at Twitter.
>>>>  @anywhere is a pure javascript layer that developers can drop in to add
>>>> Twitter features to their website.  With the User-Agent flow, we issue
>>>> short
>>>> lived access tokens that refresh as they expire.  It works great for
>>>> in-page
>>>> stuff, but many developers are also building server-side integrations
>>>> and
>>>> would love to have different longer lived access tokens on their server.
>>>>  This is a common pattern that other connect-like services built on top
>>>> of
>>>> OAuth 2.0 will also find necessary.
>>>> So, why not just use the access token issued by the User-Agent flow on
>>>> the
>>>> client server?  Overloading the use of that token is not desirable for a
>>>> couple of reasons:
>>>> 1) The client server may not be using ssl, and as such the browser
>>>> cannot
>>>> securely transfer the access token to the server.
>>>> 2) The access token lifetime policy for the User-Agent flow may not
>>>> be desirable on the server.  Specifically, the server may need a token
>>>> that
>>>> lasts for, say, two weeks instead of 15 minutes.  Additionally, the
>>>> token on
>>>> the server may have access to different resources that are
>>>> not desirable to
>>>> transmit to or through the browser.
>>>> In short, it is desirable to get two different access tokens from a
>>>> single
>>>> user authorization triggered by the User-Agent flow.
>>>> Proposal:
>>>> Make it possible to get a Web Server flow verification code from the
>>>> User-Agent client authorization request [1]. Specifically, add a new
>>>> optional parameter named "web_server_code" which when set to "true"
>>>> returns
>>>> a Web Server flow verification "code" field in the User-Agent
>>>> authorization
>>>> response.  The verification code can then be sent by the javascript
>>>> layer to
>>>> the client server, where it is then used to request an access token [2].
>>>> Love to hear your feedback.
>>>> 1: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.5.1
>>>> 2: http://tools.ietf.org/html/draft-ietf-oauth-v2-05#section-3.6.2
>>>> --
>>>> Brian Ellin
>>>> Product Manager, Twitter Platform
>>>> http://twitter.com/brianellin
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>
>>
>>
>> --
>> Brian Ellin
>> Twitter Platform Team
>> http://twitter.com/brianellin
>>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth