I agree that (3) would help a great deal. It feels like all of the attention is being given to securing the callback (2-3) and not the authorization redirect (1-2). Certainly securing the callback can work, but only if we require that "Consumers should NOT bind request tokens to accounts." I worry that putting the burden on Consumers is not viable. Certainly, my company's consumers to date have not been very savvy about OAuth and would be likely to get this wrong.
I've been playing around with a version of our site that rejects the authorization request if it doesn't happen within a short timeout or if it has been previously used to initiate an authorization request. This does require an extra redirect and some extra state after receiving the authorization request to preserve refresh and back button behavior. Jesse On Apr 28, 5:41 am, Hubert Le Van Gong <[email protected]> wrote: > I also saw 2 additional ideas that might help > (and are not necessarily exclusive with the 2 proposals): > > (3) Make Request tokens one-time only > (4) Request that the user logs in at the Consumer before the request > token request > > Are those off the table? > I think (3), although potentially difficult to deploy, would significantly > help. > Maybe (3) and (4) could be added in the spec as Best Practice or > Recommendations? > > Hubert > > On Sun, Apr 26, 2009 at 7:48 AM, Eran Hammer-Lahav <[email protected]> > wrote: > > > Let's see if we can take a quick break from the discussion and get a sense > > of where we are. Please answer the questions to follow. > > > --- > > > We have identified 2 solutions listed here: > > >https://oauth.pbwiki.com/OAuth-Session-Fixation-Advisory > > > * Signed Approval URLs > > > This proposal breaks the protocol into two separate flows, one for > > Consumers capable of launching a browser and accepting callbacks, and > > another for those who can't. It requires a significant rewrite of the > > specification because of the way the flow and signature are mixed together > > in the current Core 1.0 specification. > > > * Signed Callback URLs > > > This proposal makes the callback URL part of the signed request for Request > > Token (which does not allow an attacker to manipulate it), and adds some > > unpredictable value to the callback redirection that is needed to get an > > Access Token. > > > The spec changes include (see quick reference at the bottom): > > > - Move the oauth_callback parameter from 6.2.1 to 6.1.1 > > - Add a new parameter to 6.2.3 which is needed to make 6.3.1 > > > --- > > > Open questions: > > > 1. Am I missing a completely different alternative? If yes, please create a > > new wiki page and point to it (if you don't have access ask or email it to > > someone who does). > > > 2. Given the simplicity of the Signed Callback URLs *specification change*, > > I would like to instead of asking people which solution they prefer, to ask > > people if they have a strong objection to using the Signed Callback URLs > > solution, and if so, to explain why? > > > 3. For the Signed Callback URLs solution, what to call the new parameter > > returned in 6.2.3? Suggestions so far included: > > > - pin > > - verifier > > - chaperon > > - callback token > > - callback secret > > > 4. And, should the new parameter be added to 6.3.1 (oauth_token + > > oauth_something) or replace the value of the oauth_token parameter? > > > The second option basically returns an authorized token which is used with > > the existing secret from 6.1.2. The benefit of a new parameter is it is > > easier to follow the protocol. The benefit of reusing oauth_token to make > > 6.3.1 is that is keeps the signed request consistent with all other signed > > requests (no new parameters). > > > EHL > > > --- > > > Quick Reference > > > 6.1.1. Consumer Obtains a Request Token > > 6.1.2. Service Provider Issues an Unauthorized Request Token > > 6.2.1. Consumer Directs the User to the Service Provider > > 6.2.2. Service Provider Authenticates the User and Obtains Consent > > 6.2.3. Service Provider Directs the User Back to the Consumer > > 6.3.1. Consumer Requests an Access Token > > 6.3.2. Service Provider Grants an Access Token --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
