Here is an attempt to help spell out the OAuth security in simple terms and thus provide a framework to judge various proposed fixes. I float this as either a useful shared assumption OR a strawman to knock down so the the issue can be addressed in some other way.
Eran, in his explanation, outlined there steps that are not connected but *need* to be connected for the protocol to be secure. A. user initiates a consumer-to-provider handshake B. user logs in to provider (or verifies they are logged in) and authorizes this handshake from the provider side C. now back at the consumer, users does useful things based on the securely transacted handshake The OAuth spec MUST accomplish either of the following to close the security hole: 1. verify that the user at A is the same user at B 2. verify that the user at B is the same user at C Almost all of the proposed solution attempt to minimize the possibility that user at B is the same as user at C. Is that enough? It's true that actual "verification" will impact the user experience negatively (as actual authentication/verification inevitably does). It's probably worth thinking about what "verification" means and how that might be achieved. Otherwise, I think the community needs to decide if "minimizing possibility" is enough. --peter keane --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
