OAuth would enable slave servers to send HTTP requests directly to master servers, with assurance that a user authorized each request. If you need this, OAuth is a reasonable choice; if you don't, it probably isn't.
On Jul 18, 8:14 am, Douglas <dugca...@gmail.com> wrote: > Please be gentle ;-) ... I've read the OAuth introduction and > scenarios but I think our need is a little different ...however, I > wanted to bounce this off the OAuth community as perhaps I have yet to > see the true abstractions available in the implementation. > > Our use case: We offer SaaS services built and branded to look like > what ever site we have partnered with ... thus our site is a 'slave' > to a 'master' site where authentication takes place. The user > experience hides the fact that the user is accessing our site. When > the user needs our services, we must depend on an authentication > having taken place on the 'master' site. > > We would like to verify the request coming from the 'master' site > without having to build unique, one-off 'is that really you and is > this request good?' interactions with each master site that hosts our > content. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
