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