First, I would argue that "Facebook Connect" is less about authentication and more about authorization by the facebook user to allow the 3rd party site to access their facebook data. In this sense, while authentication can be involved, it's much more directly mappable to OAuth.
In addition there should be no issues with using OAuth as the API mechanism for invoking the "authorization" UI at the service provider. Just use the standard request_token, authorize, access_token flow. If the service provider is also the "IdP" for the user, then I don't think anything else is necessary. However, if the service provider accepts OpenIds, then the integration efforts mentioned below come into play. I probably missed something, could you please describe your use case in a little more detail? Thanks, George P.S. While the Consumer token/secret allow for two-legged calls between the consumer and the service provider, all the signature does is establish who submitted the request. There isn't yet a way to leverage this for direct user authentication via an API. But I'm not sure that's what you're looking for. JR Conlin wrote: > Senad wrote: > >> I'm looking for possibility to implement user authentication similar >> to Facebook Connect via OAuth. I understand that OAuth is not OpenID >> extension, but as far as understand Consumer can also authenticate a >> user of Service Provider, if Consumer has authorization to access >> user's data stored on service provider. In similar way how Facebook >> Connect does things: all messages are signed by Service Provided (that >> is Facebook), so Consumer just needs to verify whether user's data >> send by user are correctly signed. >> >> > Well, Facebook Connect does indeed bundle a few things together in order > to do what you want, and it's certainly possible to duplicate it using a > combination of OpenID (for user login credentialing), OAuth (for secure > third party authorization) and Portable Contacts (for contact exchange). > Take a look at the work that Joseph Smarr and Plaxo are doing for tips > about that. http://www.plaxo.com/api/portablecontacts (Heh, Facebook > uses a simple MD5 hash of the arguments + a shared secret, so in some > respects, an OpenID/OAuth combination would be more secure, but that's > beside the point.) > > One of the bigger problems, honestly, is making sure that you've got a > system that either maps the OpenID token to your existing UserID, or > uses the OpenID token as your UserID. Once you have that, it's fairly > trivial to create a table that maps to user information returned by > Portable Contacts. > > It's not as "advanced" as Facebook is (although facebook relies heavily > on the use of their Javascript libraries and localized cookies unless > you're a trusted party), and frankly, if you're running a simple app or > blog, the Facebook API is far easier to get running right now. Then > again, their system is absolutely tied to just Facebook so if your life > happens to involve other sites, well, you're not going to get them. > > The OpenConnect stuff is still very much a work in progress, so feel > free to help out. > > >> Did anybody investigated this? Any pointers how to do this? >> >> Thanks! >> Senad >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
