Hi Brian, On Apr 28, 2009, at 2:12 PM, Brian Eaton wrote:
> > On Tue, Apr 28, 2009 at 11:00 AM, John Kemp <[email protected]> wrote: >> All of these protocols are for Web-browser based SSO, and establish >> the trust between the consumer and SP (using the OAuth terminology) >> by >> relying on Web-browser technologies (ie. an HTTP redirect sent >> through >> the user's browser assures that the browser is the same one at SP as >> it was at consumer). >> >> I do not think the assumptions of OAuth are the same as for those >> protocols. At least not currently. And I would be wary of going that >> way without more thought. > > Please give it the thought, then. This is key. > https://oauth.pbworks.com/OAuth-Session-Fixation-Advisory has a > checklist that may be useful to validate your ideas. Nit: this checklist would be a bit less confusing if the order for each item remained constant (item 2 of the comparison has 'approval' and 'callback' in a different order than the other items). > > >> I think the security requirement is that you ensure that the entity >> making a request to the consumer to start the OAuth process is the >> same entity which is authenticated to the SP. Are you arguing that >> the >> callback URL suffices in that regard? > > It's sufficient for applications that can receive callback URLs. Both > of the proposals at > https://oauth.pbworks.com/OAuth-Session-Fixation-Advisory rely on the > callback URL. Having reviewed briefly the 'Signed callback URL' proposal [1], I can see how it could work, but have a couple of questions: i) It seems (but is unstated) that the consumer must have a notion of who the 'user' is (prior to issuing the initial request to the SP) in order to generate a _per-user_ callback URL (ie. callback URLs would then be required to be per-user?), and must then validate in step 3 that the user which started the process is the same one which the consumer is now redirecting to the SP? If that check fails, then should the protocol stop there? ii) Is the intent of the oauth_verifier to prevent the possibility of a similar redirect break between acquiring the authorized request token and getting the access token? Regards, - johnk [1] https://oauth.pbworks.com/Signed-Callback-URLs > > > For apps that can't receive callback URLs, you need a PIN. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
