On Sun, May 23, 2010 at 7:13 PM, Luke Shepard <lshep...@facebook.com> 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
Isn't this suggesting a strong integration as well? > - 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. I think that "Web Server" is a bit of misnomer. This flow can be used by native apps and also by JavaScript clients. The main difference between Web Server and User-Agent flows is that the former requires an extra direct call to swap the verification code. I could be missing something, but here is how I see how "User-Agent with optional verification code" can be implemented with the current spec: 1. JavaScript client starts Web Server flow with immediate off 2. user approves scopes 3. JavaScript receives verification code 4. JavaScript passes verification code down to client server 5. JavaScript does User-Agent flow with immediate on 6. JavaScript receives access token 7. JavaScript uses access token 8. When access token expires, go to 5. One problem, how does the JavaScript code know when to request a verification code, but this applies to the proposed enhanced User-Agent flow as well. Also, the proposed flow saves on one immediate call, that can be optimized by the client server returning an access token on the request that passes the verification code down. Not sure it is worth it. Does the above work? Marius - > > On May 21, 2010, at 5:50 PM, Marius Scurtescu wrote: > >> On Fri, May 21, 2010 at 1:46 PM, Brian Ellin <bel...@twitter.com> 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 <mscurte...@google.com> >>> 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 <bel...@twitter.com> 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 >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> >>> >>> >>> >>> -- >>> Brian Ellin >>> Twitter Platform Team >>> http://twitter.com/brianellin >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
