I am not suggesting changing the entire spec, just dropping the request token part.
This is what I'm getting at --> https://oauth.pbwiki.com/Signed-Approval-URLs On Sat, Apr 25, 2009 at 2:58 PM, J. Adam Moore <jadammo...@gmail.com> wrote: > > EDIT LAST POST: The second "consumer" I meant to say provider. > > On Apr 25, 12:55 pm, "J. Adam Moore" <jadammo...@gmail.com> 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" <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 -~----------~----~----~----~------~----~------~--~---
