This post originated from an RSS feed registered with Ruby Buzz
by Premshree Pillai.
Original Post: Web Services for (almost) Everything
Feed Title: Premshree's Personal Weblog
Feed URL: http://premshree.livejournal.com/data/rss
Feed Description: Premshree's Weblog
Allow me to take a side path here for a moment. I personnally wondered about this one for quite a while, until recently a friend of mine invited me to test a new web 2.0 service. Sorry, I can't tell you which, it being in private beta and all, but they did one very cool thing: You could sign in to the service using your Google Mail account. Did they struck a deal? No, the solution was much simpler: they used XMPP Authentication. XMPP aka Jabber is the underlying protocol to Google Talk. It's completely open and well documented and has some neat features which unfortunately didn't make it into Google Talk itself yet.
This is basically the foundation of a Single Sign-On (SSO) solution by Google! Hmm, why does that sound familiar? What other IM service offered Single Sign-on with an IM login?
That's right, Microsoft's Passport. Hold on, Google Talk/XMPP isn't just a SSO service, it's one that _EVERYONE_ can easily implement on their site, without the need for licensing fees and all! All your clients need is a free Gmail account.
[...]
The article goes on to explain how you could go about generating a token to authenticate against Google. Nice. Nice not because you could do that. Nice because Google doesn’t have an explicitly mentioned auth API, and you could still use it for SSO.
Those who know about the way Flickr does authentication for its web services would realize that you could actually use that mechanism to implement SSO in your own application. It’s really simple: you ask the user’s Flickr user name, authenticate the application by asking the user to grant it rights, check for validity of tokens when you need to. That’s about it!
Most of the web services we have today provide us some data (most of the Yahoo! web services, for example). These web services are typically for consumption by third-party applications. Other web services (Flickr, for example) provide interfaces to push data into their servers. Still others ask you to provide some data and the web service offers you with something functional (Yahoo! Maps, for example).
If you were to categorize these web services, they’d probably fall under one of the following categories: 1) data (pull/push), 2) functional. Now, a web service that would let third-party applications be able to do SSO would probably be categorized under infrastructure. Ditto with del.icio.us [ref]—a tagging platform.
Of course, if an auth mechanism is actually intended to be used for SSO by third-party applications, there’ll probably be more that the web service would have to offer—ability to define profile objects, user registration, etc.
It’s interesting to imagine a world where we have all (or, rather, many) of these—data, infrastructure, some functionality—available. You need to actually concentrate on what you really want to do with your application, rather than bothering about fundamental needs.
Previous Topic
