Isn't that what OpenID is for?
July 3, 2007 3:16 PM
I have a potential web development client who wants users of their site to be able to log in to their site using existing IDs from AOL, Facebook, Google, Windows Live, Yahoo, and other social networking sites and have their site keep them logged in at the other sites. Is this possible?
Isn't that what OpenID is for?
Isn't that what OpenID is for?
Supporting these things would be your problem even if OpenID is used. Some can be done:
AOL with OpenID, Yahoo with OpenID (third party), Facebook API.
posted by genghis at 3:33 PM on July 3, 2007
AOL with OpenID, Yahoo with OpenID (third party), Facebook API.
posted by genghis at 3:33 PM on July 3, 2007
I work with the folks who created OpenID initially, and we've deployed a couple million OpenID identities -- this is exactly what the system is designed for.
For the specific brands you've listed, only AOL provides OpenID identities for their AOL and AIM users. There is a third-party service that will allow you to use Yahoo logins via OpenID, which is a little complicated for most normal people, and Microsoft's CardSpace identity system will accept OpenIDs but doesn't use them for sign-in.
That being said, there are over 100 million OpenIDs already created, so there's starting to be critical mass, and you can fake some of the other stuff using Google's and Facebook's and Yahoo's proprietary authentication APIs.
The real question is what benefit single sign-on will provide to your users - it's a tough concept to explain, and usually makes the most sense when they see some benefit (in terms of reputation or authentication or social network) for bringing their identity from elsewhere.
posted by anildash at 3:42 PM on July 3, 2007
For the specific brands you've listed, only AOL provides OpenID identities for their AOL and AIM users. There is a third-party service that will allow you to use Yahoo logins via OpenID, which is a little complicated for most normal people, and Microsoft's CardSpace identity system will accept OpenIDs but doesn't use them for sign-in.
That being said, there are over 100 million OpenIDs already created, so there's starting to be critical mass, and you can fake some of the other stuff using Google's and Facebook's and Yahoo's proprietary authentication APIs.
The real question is what benefit single sign-on will provide to your users - it's a tough concept to explain, and usually makes the most sense when they see some benefit (in terms of reputation or authentication or social network) for bringing their identity from elsewhere.
posted by anildash at 3:42 PM on July 3, 2007
Why would logging into one site log them out of another?
posted by rhizome at 5:23 PM on July 3, 2007
posted by rhizome at 5:23 PM on July 3, 2007
The real question is what benefit single sign-on will provide to your users - it's a tough concept to explain, and usually makes the most sense when they see some benefit (in terms of reputation or authentication or social network) for bringing their identity from elsewhere.
I've been involved one way or another in 3 different "single sign-on" projects. It's an idea that seems to crop up over and over without ever taking over. It's the kind of idea that sounds more useful the less time you've had to really think through what's in it for users, and how it would work for them in any detail. anildash speaks wisdom, for this to be viable one imagines there has to be more to the project than just "save the trouble of logging in more than once", what else is needed, what other data has to be transfered from facebook etc to your clients site?
posted by scheptech at 8:00 PM on July 3, 2007
I've been involved one way or another in 3 different "single sign-on" projects. It's an idea that seems to crop up over and over without ever taking over. It's the kind of idea that sounds more useful the less time you've had to really think through what's in it for users, and how it would work for them in any detail. anildash speaks wisdom, for this to be viable one imagines there has to be more to the project than just "save the trouble of logging in more than once", what else is needed, what other data has to be transfered from facebook etc to your clients site?
posted by scheptech at 8:00 PM on July 3, 2007
I don't think you SHOULD do this, but you could:
* Take a username/password from the user
* Pass it to whatever 3rd party you're trying to log into
* use screen-scraping techniques to verify whether this successfully logged the user in or not, and treat them as logged in, or not, accordingly
I've been involved in a lot of projects where we wanted to scrape data from web sites that you have to log into, so I've done things like this before, just not for this particular purpose.
I can't comment on how this would affect whether you'd be logged out from the other pages.
It's a tremendous pain in the ass, since any of those sites can change things ranging from how their pages look (making scraping difficult) to how logins get processed, and you'll have to re-implement that service.
posted by RustyBrooks at 10:09 PM on July 3, 2007
* Take a username/password from the user
* Pass it to whatever 3rd party you're trying to log into
* use screen-scraping techniques to verify whether this successfully logged the user in or not, and treat them as logged in, or not, accordingly
I've been involved in a lot of projects where we wanted to scrape data from web sites that you have to log into, so I've done things like this before, just not for this particular purpose.
I can't comment on how this would affect whether you'd be logged out from the other pages.
It's a tremendous pain in the ass, since any of those sites can change things ranging from how their pages look (making scraping difficult) to how logins get processed, and you'll have to re-implement that service.
posted by RustyBrooks at 10:09 PM on July 3, 2007
* Take a username/password from the user
* Pass it to whatever 3rd party you're trying to log into
If you do this, expect the 3rd parties to object very loudly to you asking their users for their passwords. This is basically phishing with good intentions.
posted by mendel at 6:49 AM on July 4, 2007
* Pass it to whatever 3rd party you're trying to log into
If you do this, expect the 3rd parties to object very loudly to you asking their users for their passwords. This is basically phishing with good intentions.
posted by mendel at 6:49 AM on July 4, 2007
This thread is closed to new comments.
At any rate, without knowing more about the project requirements, I would suggest steering your client toward enabling their site with OpenID and looking into interfacing specifically with AOL, Yahoo, Google and Facebook if they need more in-depth user information from site to site.
posted by annathea at 3:29 PM on July 3, 2007