This also has the added benefit of letting consumers use a provider as an identity surrogate, relying on the user's ability to authenticate w/ the provider, i.e., the recent "Sign in with Twitter" style functionality.
-- Dossy Shiobara [email protected] -----Original Message----- From: "J. Adam Moore" <[email protected]> Date: Sat, 25 Apr 2009 12:58:20 To: OAuth<[email protected]> Subject: [oauth] Re: OAuth Security Advisory EDIT LAST POST: The second "consumer" I meant to say provider. On Apr 25, 12:55 pm, "J. Adam Moore" <[email protected]> wrote: > What I should have added was that using my solution, the consumer is > completely capable of being stupid and giving the consumer a redirect > that doesn't require a login on the consumer side, but they can also > take a gun and blow their brains out. You can't stop people from being > stupid and it's not the Providers job to even care if the redirect > they were given is secure. > > I'll say it again. I AM NOT CHANGING THE OAUTH MODEL. Everything works > exactly as before EXCEPT the request token HAPPENS AFTER > AUTHENTICATION ON THE PROVIDER SIDE. That is all. That fixes > everything. Triggering the authentication flow AS IT IS NOW from > behind a login ON THE PROVIDER SIDE. An attacker cannot generate a > reusable token or spoof/calculate an access token. Totally secure > would be the scenario I explained where both sites redirect behind a > login. It's simple. It's easy. Lets do it. > > On Apr 25, 12:41 pm, "J. Adam Moore" <[email protected]> wrote: > > > Logically I find that the only way to guarantee that two different > > users at two different sites are really the same person is to make > > them self authenticate BEFORE establishing a secure communication. By > > having both the Provider and Consumer redirect to a spot behind a > > login on both sites it fulfills this requirement without breaking the > > current model or people's brains. Making something simpler for the > > sake of simplicity is simply not a compelling argument against > > requiring habeas corpus at each end. I think too many people are > > trying to adjust the model instead of the implementation. The model is > > fine once you can prove (on each end) that it is the same user. Not > > caring what your login is on the consumer? What does that even mean? > > Either the redirect url is publicly accessible or it requires a login. > > I don't need to know WHO you are or care if you are logged in or not, > > but nothing is going to happen until you prove that you are who you > > are trying to associate with. This also leaves sites able to craft > > their redirect urls to contain either unique paths or unique tokens or > > both without breaking the protocol or damaging the current information > > exchange model. I still favor a solution that doesn't add or take away > > anything from the current model. Basically a protocol that reorders > > passing information to occur after user authentication and tightens > > rules on where redirects point. > > > On Apr 25, 12:12 pm, Josh Roesslein <[email protected]> wrote: > > > > We don't really need the user to be logged into the consumer to generate > > > our > > > token. The service provider should not care what our login is on the > > > consumer. > > > All it cares about is authorizing a consumer access to our data. We log > > > into > > > the provider and authorize the creation of an access token for the > > > consumer. > > > We then visit this consumer and hand over our token (either manually for > > > desktop apps or by being redirect by a callback w/ token attached). > > > The consumer can now access our data. It is up to the consumer now on how > > > to > > > store this token. (Here is a link to the > > > flow:http://pastie.org/pastes/457478) > > > > I don't think preventing middle attacks or phishing is really what oauth > > > should be doing. SSL does this well and it should be used for the transfer > > > of the token > > > from the provider to the consumer. This way an attacker can't intercept > > > the > > > token and use it to log in to the consumer under their account and access > > > our data on our provider account. > > > > The user can't be easily phished since both URL's (authorization URL and > > > callback URL) are verifiable by SSL. Also the callback is either stored on > > > the service provider or signed in the authorization request by the > > > consumer. > > > > On Sat, Apr 25, 2009 at 1:43 PM, J. Adam Moore <[email protected]> > > > wrote: > > > > > The idea is that the communication between the Consumer and Provider > > > > sites consist of urls that are composed behind user logins ON BOTH > > > > SITES at the same time. I believe that this prevents simpler attacks > > > > like man in the middle or DNS or url tampering and allows secure token > > > > generation based on session authentication, which, when employed > > > > properly, cannot be spoofed from either end or the middle. > > > > > On Apr 25, 11:21 am, Josh Roesslein <[email protected]> wrote: > > > > > I don't really see the need for the double trip to the service > > > > > provider > > > > to > > > > > perform the login and authorization. > > > > > This can be done in one single step like I have outlined in my > > > > > proposal. > > > > > User logs into provider, grants access, and returns back with the > > > > > token. > > > > > The less work we do in our flow the less likely an attacker can find a > > > > hole. > > > > > The double trip just creates a second chance for an attack. > > > > > > On Sat, Apr 25, 2009 at 12:33 PM, J. Adam Moore <[email protected] > > > > >wrote: > > > > > > > I'm writing a blog post to explain why I think I have a solution, > > > > > > but > > > > > > I believe it is as simple as moving the provider login to before the > > > > > > consumer token generation which is triggered by a provider-side > > > > > > redirect. This is simply playing keep-away with redirects, but it > > > > > > arguably works if your goal is web-based "sudo" permissions for an > > > > > > app > > > > > > or site. > > > > > > > 1) User clicks on Consumer site link to Provider (no tokens or > > > > > > anything, just a request for a protected area on the site that IDs > > > > > > the > > > > > > Consumer) > > > > > > 2) Link is protected, requires login. (This should generate your > > > > > > session/user identifier) > > > > > > 3) Once logged in user is redirected (with a unique identifier, > > > > > > encrypted or not) back to a Consumer redirect page > > > > > > 4) Consumer generates request token and automatically redirects back > > > > > > to Provider's user authorization page > > > > > > 5) User approves access, Provider automatically logs user out, > > > > > > callbacks are optional. > > > > > > 6) Desktop apps can use a one-time-only password-reset-style cut-n- > > > > > > paste token IN THE NORMAL PASSWORD FIELD to authenticate. > > > > > > > There are many suggestions that duplicate tokens, information, or > > > > > > steps in the process. If the initial association of the process > > > > > > with a > > > > > > user is the problem, then requiring a login first will ALWAYS be the > > > > > > solution. The flow is fine as it is, with the small exception that > > > > > > the > > > > > > provider-side login requirement needs to be moved up in the process. > > > > > > > The game of keep-away doesn't hinge on obfuscation of the McGuffin, > > > > > > but in passing it outside of the reach of the attacker. If an > > > > > > attacker > > > > > > can use redirects to jump into the position of a player, then we can > > > > > > use redirects to never pass the McGuffin to the same position with > > > > > > the > > > > > > same info. > > > > > > > As far as I can tell there was only one INSIGNIFICANT flaw with > > > > > > OAuth > > > > > > and that was the Provider login requirement happening too late. > > > > > > That's > > > > > > it. Once you do that you can check the session or user, send nonces > > > > > > or > > > > > > encrypted user_ids with the initial redirect, or just about any > > > > > > crazy > > > > > > security measure you can think up. > > > > > > > Steps 3,4,and 5 are invisible to the user and end with a token that > > > > > > can be used as a temporary password which triggers token > > > > > > authorization > > > > > > and association with a seamless manual option that appears to jump > > > > > > straight to step 6. Because all of this is happening behind a > > > > > > Provider > > > > > > login, it is as secure as you're going to get it without > > > > > > fundamentally > > > > > > changing the structure of the whole process. > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
