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" <jadammo...@gmail.com> 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 <jroessl...@gmail.com> 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 <jadammo...@gmail.com> 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 <jroessl...@gmail.com> 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 <jadammo...@gmail.com > > > >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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
