[web] Cross site authentication for social networking
Say I own one web site, and I want to make it available to users of another web site, which I don't own. The first site would use the user's publicly visible data from that second site (in accordance with privacy policies, copyright, Terms of Use, etc) as part of its content, as authorised by that user.
How can I authenticate that a person on Site 1 is actually a given person on the other site? What methods are available, and how much cooperation will they need from the user, the other site, or both?
One rudimentary example I've seen works along the lines of "insert this arbitrary string into your profile/journal temporarily to prove it's you". Site 1 then scrapes Site 2's HTML to find this key phrase and uses this to verify that the page or profile edited on Site 2 belongs to the current user.
Another example might be to scrape an email address from Site 2 and send a secret key to that address, which has to be entered into Site 1 by the user. This will only be possible if they own that email address. It will also only be possible if Site 2 publishes email addresses. :)
More secure methods might include direct communication between the 2 sites, or some sort of external ID (eg. OpenID), but I neither know much about such methods, or know whether they involve a great degree of cooperation from Site 2. What are the simplest and/or most standard approaches here?
OpenID is probably a good solution for this. It has several avenues of authentication: providers like LiveJournal, Flickr, Yahoo, etc. explicitly support it, and there's also a "put this in your HTML" method which will work on blogs. Ultimately, of course, it comes down to the capabilities particular site. If I can't post content on the site, and don't have an email address on the site, in what way am I a "person on the site"?
Unfortunately, I expect that compelling Site 2 to support OpenID is quite a big undertaking. Is there anything a bit more lightweight? And what's this about putting it in the HTML?
For my purposes, I'd assume the user of Site 2 can edit a personalised page in some way. I'm also interested in things Site 2 can do to confirm that a given person is indeed one of their members, if possible without requiring the user to enter their username and password into Site 1 to relay it across.
For my purposes, I'd assume the user of Site 2 can edit a personalised page in some way. I'm also interested in things Site 2 can do to confirm that a given person is indeed one of their members, if possible without requiring the user to enter their username and password into Site 1 to relay it across.
Quote:Original post by Kylotan
Unfortunately, I expect that compelling Site 2 to support OpenID is quite a big undertaking. Is there anything a bit more lightweight? And what's this about putting it in the HTML?
If the user can put a couple of tags in the <head> section of their webpage, they can securely and unambiguously claim that page as their own and relate it to their OpenID, regardless of whether Site 2 has ever even heard of OpenID.
Ah yes: section 3.1 of the OpenID Authentication 1.1 spec.
Still, I'd expect 95% of places wouldn't let you tamper with the head tags as a mere user, so it's probably only useful for blogs and the like.
Still, I'd expect 95% of places wouldn't let you tamper with the head tags as a mere user, so it's probably only useful for blogs and the like.
Quote:Original post by Kylotan
Still, I'd expect 95% of places wouldn't let you tamper with the head tags as a mere user, so it's probably only useful for blogs and the like.
Indeed. OpenID is the only thing approaching "general" for cross-site authentication. Beyond that, you'll need to do per-site things, like having them insert a number into some useless personal information field (like ICQ number) or emailing them or having them post something.
Unfortunately, the current state of things makes what you want to do incredibly difficult unless Site 2 has made attempts to allow you to do this. Although OpenID has been popular in tech areas recently, a vanishingly small number of people know what it is, know that they have one (millions of people have them), or care to use it. This is compounded by the fact that there are a lot of OpenID providers but relatively few OpenID consumers.
Further, OpenID is still not very user friendly. Entering a URL as a login is not intuitive today and most people with OpenIDs (for example, all the users of AIM) might not even know what that URL is. There are proposals to link an ID with an email address which would make life a lot easier, in my opinion, but right now they are just proposals. So, even if Site 2 supported OpenID you'd probably be fighting an uphill battle trying to get users to use it.
Realistically, right now I think your best option is to contact Site 2 and tell them what you'd like to do and see if they have any mechanism to help you out. If they dont, scraping for either an email address or some arbitrary piece of information is probably your only option.
Further, OpenID is still not very user friendly. Entering a URL as a login is not intuitive today and most people with OpenIDs (for example, all the users of AIM) might not even know what that URL is. There are proposals to link an ID with an email address which would make life a lot easier, in my opinion, but right now they are just proposals. So, even if Site 2 supported OpenID you'd probably be fighting an uphill battle trying to get users to use it.
Realistically, right now I think your best option is to contact Site 2 and tell them what you'd like to do and see if they have any mechanism to help you out. If they dont, scraping for either an email address or some arbitrary piece of information is probably your only option.
Is it feasible for site 2 to expose a web service through which site 1 can authenticate a user? If so, you would probably still require a simple login procedure on site 1 though.
That's feasible, but it requires changes/additions to site 2 which you don't own.
To make this discussion a whole lot easier: which site(s) do you want to scrape to begin with? Some sites do provide things like an API which you can not only use to authenticate a user, but also to get at (some of) the content (which means you don't have to scrape HTML. Yay!)
To make this discussion a whole lot easier: which site(s) do you want to scrape to begin with? Some sites do provide things like an API which you can not only use to authenticate a user, but also to get at (some of) the content (which means you don't have to scrape HTML. Yay!)
I'm not really asking how to do a specific thing, just wondering if there are ways I hadn't thought of. I'm also interested in what Site 2's API for authenticating a user to another site could be - if it involved you entering your Site 2 username and password into Site 1 then I can see that being unacceptable for many users.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
