pkeane wrote: > > This seems like it addresses the the hole adequately as long as an > attacker that cannot manipulate the callback url cannot succeed (I > think that's true...). > > Further thought on this whole thing makes me think that a one-time > only token exchange plus a non-modifiable callback are what's needed. > Maybe OAuth++ or somesuch can provide an extra authentication piece on > the front end for providers wishing to require that. Also, making it > very explicit on the provider's OAuth page that the user is > establishing an authenticated access agreement between the Consumer > app and the Service Provider that *they* own (i.e., are responsible > for, can revoke at any time,etc.). I also think (as I have said > before) that the spec should be explicit about the social engineering > exploits that are possible. > > > I have to agree with you on the one-time token exchange, but as you had mentioned before, mandate it between the consumer and SP. It really should be some code/pin/session key (whatever you want to call it) that the user enters on the consumer side. This would then need to be entered on the SP side as well. Currently there is not enough human integration within the flow. With this type of flow, the SP knows or at least can expect that the user trusts the consumer to some degree because they gave the same key to both parties. Wording on the SP's page of what is going on is not enough. The user also needs to be actively involved with the consumer simply is not enough imho.
There seemed way too many responses to your original proposal that it would cause a bad user experience. I really don't see how requiring the user to enter some additional piece of information in an extra step is enough to cause a bad user experience compared to the additional security it provides. This step really should not be optional or an additional extension as there should be a consistent experience the user can come to expect. The user should know that regardless of how authentication is handled by the SP, this key is always going to be required by them during the flow. Too many people want simplicity at the sake of security. I am a strong advocate of Information Cards. Its central focus is the user; the user is the central point for flow of information. At every point they know who is getting what and why. The technology used is complex and unfortunately its not widely available for usage yet. I would hope tough that it at least serves as a model to show how important the user is and that they should be more engaged in the aware of what is happening around them. Rob --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
