I still don't think passing session information through oauth for the callback is a good thing. You could simply set a cookie in the browser if you are a site to hold any information you will need on the callback. Example: storing the URL of the page the user was last on. Maybe we could add a parameter (oauth_callback_data) which the consumer could set that will be returned back on the callback. This of course would have to be signed still since an attacker could figure out what this data does and exploit it in some way.
With the way I outlined the flow their is no pin exchange. The user by agreeing to generate a token for the consumer is enough. We know by signing that the consumer the token is being generated for can only be used by that consumer. Their is no need to exchange a pin to verify this consumer. Once the callback is executed with the access token attached, it is now up to the consumer to properly use this token. They must either bind it to an account by having the user login on the callback(or use a cookie session if the user logged in before starting the oauth flow) or by creating a temporary session and binding the token to that. Since the callback can't be tampered with (it's registered with the SP) we know the user will be directed to the correct location with their new token. We could for extra security return an "authorization token" instead that must be swaped by the consumer for the final access token for some extra security. On Sat, Apr 25, 2009 at 5:34 AM, Rob Richards <rricha...@cdatazone.org>wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
