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 -~----------~----~----~----~------~----~------~--~---
