As long as people are willing to trust their Twitter log-in information to third parties - and don't look carefully at URLs before they log into websites - and as long as a small number of bad actors want to pee in the social media swimming pool, this kind of thing will continue happening.

Apparently there's no substitute for ruthlessly and constantly policing your own feed, thoroughly investigating services before you sign up for them, double-checking the URL every time you are about to enter info into a form, and regularly purging your OAuth settings of services you no longer use.

Also, to be safe, change your password regularly... you don't have to be obsessive about it: every three hours or so should be enough. And because erring on the side of caution is always a good idea, fake your own suicide and change your identity at least once a year.

And you thought Twitter was going to be fun? Slacker.

More Noise to Signal.

Just last week, MySpace also announced that its users can now sync their updates with Microsoft's Live profiles. For now, the new two-way sync feature only works with Twitter, though the company notes that it will soon support other networks as well.

AOL also just announced two-way syncing with Twitter when it launched its AIM Lifestream service last week.  Overall, these services aren't very earth-shattering, but it is good to see that MySpace continues to open up and create more links with other services.

It's also becoming increasingly clear that Twitter is now the de facto clearinghouse for status updates. Pretty much every new service that features status updates already pushes updates to Twitter and now most of the older services are also (slowly) coming on board.

At some point in conversation Hammer-Lahav realized that the problem went far beyond the Twitter implementation. The OAuth protocol had an inherent vulnerability; big companies like Google, Netflix and Yahoo had implemented OAuth and scores of tiny startups had too.

The Nature of The Problem

The problem was a vulnerability to something called a "Session Fixation Attack." The gist of it is this. Services supporting OAuth let their users pull data into other websites for reuse around the web. In order to do this securely, the 3rd party site has to ask the original site for permission. This might be a new little website asking permission to import your Gmail contacts or to post to Twitter through their site instead of Twitter.com. OAuth was born from the work that Flickr did to create a secure way that other applications could be granted permission to access your photos for printing, editing or posting elsewhere.

The problem arose if an attacker could convince you to complete their request for account permission with your login. At the end of the process they would have access to your account.

Hammer-Lahav explains how this works in detail and offers flow charts in his blog post explaining the technical nature of the problem. For another explanation of this kind of attack see Mitja Kolsek's paper titled Session Fixation Vulnerability in
Web-based Applications (PDF), which was published in 2002. In other words, this is not a new problem - it was just newly discovered to be an OAuth vulnerability.

How It All Went Down

Eran Hammer-Lahav was at FOOCamp when he realized this was a problem that extended far beyond Twitter's implementation. All 30 companies currently offering OAuth were vulnerable. MySpace, Yammer, PhotoBucket. Google, Netflix, Yahoo. Millions of peoples' accounts were at some risk.

If OAuth was software, a fix could be implemented and pushed out to everyone who was using it. But it's not, it's just a standard-based specification implemented out in the wild and no one party is in charge of it. Someone had to do something though, and they had to do it fast.

The first thing Hammer-Lahav decided to do was call up Alex Payne, API lead at Twitter. Though Twitter had done everything right, it was a particular Twitter implementation that revealed the whole problem and it had only been out for a few days. (We thought it a big enough deal that we wrote a whole post about that implementation.)

Twitter shut down the OAuth option for login within 30 seconds of his phone call, Hammer-Lahav says. They did it without explanation, because they were asked to keep quiet about the security problem for one week - in order for all the providers to get a chance to respond before the security problem went public and could be exploited.

Developers cried out that Twitter was shutting down technology essential to their business without warning - and not for the first time. Robin Wauters wrote a post on TechCrunch channeling developer anger over the shut-off. (Lest we imply too much criticism we'll note that we've written very similar stories ourselves.)

Twitter was widely criticized - and they kept their mouth shut, saying only that it was a temporary problem that would soon be resolved. "I can't stress enough how noble Twitter's behavior was yesterday," Hammer-Lahav told us. "Twitter bashing is a sport now and it's a sport that sells ads. Techcrunch wasn't aware of the security threat but it put Twitter in a position where if they were going to talk about it then they would put other companies at risk. We told Twitter that it was going to go public so do your own PR management and they did a good job. The emails sent by other providers to Twitter thanking them for taking that hit have been amazing."

After contacting Twitter, Hammer-Lahav started emailing all 30 companies listed as OAuth providers with Chris Messina's help. Half of them had representatives at FOOCamp, the event he was calling from. He explained the problem to them as he was able to reach people and asked them not to discuss it until next Thursday, one week later. He knew it would be a difficult secret to keep with so many parties involved, including the frustrated developers trying access all of those companies' OAuth APIs.

"At first it took me half an hour to explain the problem," he says. "By the next day I had the explanation down to 30 seconds." Within 12 hours the group discussing the problem knew there was no simple solution - it could require changes by OAuth providers and outside applications that consume OAuth permission in order for everything working again.

The group of OAuth providers formed an email list to discuss the problem and fifty people from 30 companies joined in. Deciding to focus on communicating with the initial service providers was a decision that had to be made. "You have to triage the parties involved," Hammer-Lahav says. Providers needed extra time to deal with the problem because they couldn't just plug the hole or pull the plug easily; FireEagle, for example, only has an OAuth API - there's no other way for the service to function.

OAuth is being advanced by a decentralized community of developers and other parties, but Eran Hammer-Lahav has been its most visible advocate. He's gained years of experience in the trenches fighting for a variety of open standards. He talked to every OAuth provider on the list and volunteered to act as the Community Threat Response Contact. Yahoo, his employer, told him to take as much time and do whatever he needed to deal with the problem. The company put Allen Tom in charge of Yahoo's response and donated Hammer-Lahav's paid time to the community effort. "If I was working for a different company this might not have been possible," he says. "Yahoo! had a whole team of people managing their own response to the situation."

All thirty companies sprung into action to neutralize the security risk and prepare their respective technical responses. Mashery co-founder Clay Loveless and team pushed back other work to pull all nighters and others pitched in as well. Everyone was an equal participant in working together, from single person startups to multibillion dollar companies. "Yahoo and Google put engineers on the line helping people with small startups to review solutions they were going to deploy," Hammer-Lahav says. "Usually the big guys figure it out amongst themselves and leave everyone else to their own devices. This felt like a real community. There was no liability because it was casual advice. Security people are expensive. Some startups don't even have in-house engineers, they are entirely outsourced."

One by one many of the providers shut down their APIs and one by one they implemented solutions.

By Wednesday, one day before the self-imposed period of silence was over, there had to be a lot of pressure built up behind the scenes. Alex Payne, the man in charge of the Twitter API and a guy who is much less grumpy than you'd probably be if you had his job, started getting visibly frustrated. "The view from under this bus is really something," he said on Twitter. "Nobody in the tech press has bothered to contact me for comment on the OAuth issue. Why bother with facts when speculation drives clicks?"

Just after noon on Wednesday, CNet's Caroline McCarthy reported that Twitter and others had pulled OAuth support because of a security problem in the spec. "In the interest of online safety," she wrote, "CNET News has chosen not to make the details of the security hole public." McCarthy was at FOOCamp as well and may have heard about the security issue then, but decided to more or less respect the wishes of the developer community and hold off writing about the issue at all until just before the deadline lifted. If that was the case then she both won accolades from involved parties for her discretion and got a lot of pageviews for jumping deftly on the story after the threat had mostly passed but before others wrote about it.

Minutes after the real story was out, Twitter posted about it on the company blog. Then the official OAuth blog posted about it, linking to McCarthy's post and publicly thanking Twitter for taking all the heat for days. Chris Messina worked fast to update the site and co-ordinate the community response. Then API service provider Mashery, the company that powers OAuth APIs for Netflix and many other companies, posted about it on its blog, assuring customers that the problem was small and under control and thanking Twitter as well. Finally Dave Winer, a web forefather and hardcore Twitter critic, made a post on his blog urging people to lay off Twitter and appreciate the way they were communicating with people about a number of intersecting and difficult technical problems.

One day later, one week after the community responding to the OAuth threat called for a week of silence to come up with a solution - Twitter announced that its OAuth API was back.

That was yesterday and by today almost all of the 30 OAuth providers have OAuth back up and running. There are two different long-term solutions in the works that are being debated on the email list as we speak. Hammer-Lahav says he expects a revised draft of the spec will be ready next week.

And that's how a decentralized community solved a security threat in an open identity spec, quickly. One company (Twitter) took a risk at implementing a new technology advocated by an employee of another company (Yahoo's Hammer-Lahav), then an engineer at yet another company found the beginning of the security hole, then news of the whole problem was sent out to contacts on a Wiki, an email list was formed, companies donated their employees' valuable time to aid in the effort, everyone more or less kept their mouths shut (including the unfairly criticized Twitter) and then everyone worked together to find a solution just in time. I think that's a pretty cool story.

Lessons for the Future

Hammer-Lahav took the lead in responding to this crisis and says he did it with the future of crisis response in open web communities in mind. Creating a template now for the future is only so possible, though. "In a year this same approach isn't going to work because too many businesses are going to depend on the providers," he says. "If we don't find a way to deal with this in the future then companies will remain very cautious about relying on multiple data sources." He says that people want to create a database listing all the parties involved in technologies like this, but prioritizing who gets talked to first will depend on the nature of the threat.

Finally, Hammer-Lahav says that more companies need to empower more employees to step up and take leadership in this kind of situation. The combination of technical, people and process skills is rare but those people need to be found. "It's not sufficient to have only Chris Messina and I as the two people who can do this," he told us. "We need other companies to step up and say there are people in their organization that can support the community. Yahoo said 'you're going to go do this for the community for as long as it takes,' Yahoo was paying me to manage the community threat in a way that was not purely in their self interest."

Can open communities advocating for an open web respond quickly and effectively to inevitable security issues? It sounds easier said than done, but for now we've got at least one very interesting story that says it is possible.

The team at inuda - Jonathan "@madmotive" Markwell specifically - reports that 150 other developers have been selected to participate in the OAuth private beta.

And then there's the Twitter OAuth page, that allows developers with registered apps to review their applications using Twitter. Chris Messina shares the beta user view, as well.)

How do you know if you're in the beta? According to the Twitter Development group:

"If you're one of the 150 or so people included in the closed beta your settings page (http://twitter.com/account/settings) now contains a 'Connections' tab. In the sidebar is a little information and a link to register your very own application."

Needless to say, the news was well received by the Twitter development community.

Granted, Twitter OAuth is only in limited beta, but given Markwell's tweets and the inuda post it appears to be a straightforward implementation:

"We managed to get a prototype up and running within a few minutes with no problems so we think it's fair to say that you should never give your Twitter password to anyone ever again. In a few weeks all developers of Twitter applications will have access to OAuth and they'll have no excuse other than laziness for not using it."

Could we be seeing the end of apps that ask for your Twitter password? Will OAuth make an appearance in tomorrow's release of Tweetdeck? We can only hope.

If you'd like to befriend the ReadWriteWeb staff on Twitter here are our accounts - we'd love to meet you too!

Plaxo and Google have collaborated on an OpenID method that may represent the solution to OpenID's biggest problems: it's too unknown, it's too complicated and it's too arduous. Today at the User Experience Summit, Plaxo announced that early tests of its new OpenID login system had a 92% success rate - unheard of in the industry. OpenID's usability problems appear closer than ever to being solved for good.

Plaxo, primarily known for the noxious flood of spam emails it delivered in its early days, is now an online user activity data stream aggregator owned by telecom giant Comcast. The Plaxo team has been at the forefront of the new Open Web paradigm best known for the OpenID protocol.

The Flow

The method Plaxo has been testing is called an OpenID/OAuth combo, in collaboration with Google. What does that mean, in regular terms? It means that Plaxo told users they could log in with their Gmail accounts as OpenID by clicking a link to open a Gmail window, then Google asked for permission to hand over user contact data using the OAuth standard protocol. Once login was confirmed, whether contact data access was granted to Plaxo or not, the Gmail window closed and users were returned to Plaxo all logged in. No new accounts, no disclosure of Gmail passwords to Plaxo, no risky account scraping and no need to import or find friends on the new service before immediate personalization could be offered.

This is a very different flow than most OpenID "relying parties" have followed before - but it won't be for long.

The Success Rate

Plaxo reported today that it has seen a staggering 92% of users who clicked on the "log-in with Gmail" button come back to Plaxo with permission to authenticate their identities via Gmail granted. Of those who returned, another 92% also granted permission for Plaxo to access their contacts list. Only 8% of the people who clicked to log in with a standards based 3rd party authentication ended up deciding to bail instead. That's the kind of ease-of-use that people presumed only Facebook Connect could provide.

When Plaxo engineers moved to turn off the short-term experiment, the business team said no way.

We expect to see this basic flow get iterated on even further. We hope it will ensure that every OpenID provider has some exposure and not just the big email providers, and we expect the pop-up action to be made increasingly unobtrusive.

This could be the day when OpenID became a far more realistic prospect than it has seemed before.

How It Works

The "hybrid approach" - currently available in a limited beta - that Google and Plaxo have employed uses OpenID to sign in, then invokes OAuth for delegated authorization, and finally calls on the Google Contacts API to access information about contacts. And it does all of this transparently to the end user.

The first step in the Plaxo-Google scenario involves a new user being invited to Plaxo by a friend via Gmail. The invite understands the user is logged into the Google system and prompts the recipient with a "Sign up with my Google Account" button.

After clicking the button, the new user is directed to a Google Accounts page and asked to confirm their identity. The user is also given the option of allowing Plaxo to remember him or her in the future.

Accepting the sign-in request allows Plaxo to have access to the user's Google account credentials and the contacts associated with that account. The end result? The user now has a Plaxo account without all the rigamarole generally associated with a new account setup - and without a new username and password to track.

Why This Matters

While the concept of site-specific logins made sense in the early days of the Web, the idea of users being forced to develop a new identity, username, password, and profile on every site they visit - including adding all the same people as connections, over and over again - seems almost laughable today. It's definitely not scalable. Especially as password requirements become more and more stringent.

With the launch of Facebook Connect, the idea of a digital identity that could follow users from site to site moved from bleeding-edge tech people to a much larger contingent of the general populous. And the ease-of-use demonstrated by Facebook Connect put some friendly pressure on the OpenID contingent to improve the way they were managing the login process.

Plaxo's and Google's demonstration is something that could improve usability for all OpenID logins, reducing the series of handoffs that tend to frustrate and confuse users. But as Eric Eldon of VentureBeat notes, there is still more to be done:

"Multi-site sign on, like what the companies are announcing today, will be more compelling when it can bring integration down to one or zero clicks, but this is certainly a step in the right direction."

Who Wins? Everyone

This isn't a "winner takes all" pursuit or an "either/or" situation. We are participating in a Web environment where both Facebook Connect and OpenID can co-exist, because there are different applications that make both options viable and useful.

Personally, I'm not likely to use my Facebook account to access my bank and credit card accounts. But I am likely to use my Facebook credentials for social sites that would be enhanced by my existing Facebook connections. Similarly, my OpenID isn't always the right answer.

Facebook has momentum and a fervent user base. OpenID has a who's who of tech companies getting behind the concept as the preferred way to manage digital identities. Neither of these identity options are going away anytime soon.

What's best about the current situation is the rivalry between the two camps: one proprietary and easy-to-use, one open and more complex. It will be interesting to watch the two solutions push one another to become more and more simple for the end user. Because in that case, we all win.

Today Twitter opened up trial access to a new user sign-in protocol for third party developers - until it was swamped by demand and the trial was closed just two hours later. This isn't just a geek story, though, this could impact all users of Twitter and other sites all around the web.

Hi, It's Nice to Meet You - Can I Have the Keys to Your House?

Twitter's hype and VC fortunes are largely founded on interfaces on desktops, iPhones and other unaffiliated webpages - built by developers who don't work for Twitter. Those applications are all about interacting with user data stored on Twitter's servers, and yet the company has offered nothing but the simplest method of accessing that user data by those outside apps.

The makers of everything from desktop apps like Tweetdeck and Twhirl, to web services like FriendFeed, Twitterfeed and others have been required to ask users to give up their Twitter usernames and passwords in order to read and write to Twitter user data. And apps built outside of the Twitter.com web page are by far the best way to post messages to Twitter.

Who wants to give some brand new website they've never seen before the password to their Twitter account - an increasingly important part of millions of peoples' communication online? The fact is, many of us are doing so every day - and it makes a lot of us very uncomfortable.

The recent hacking of Twitter accounts wouldn't have been prevented by the steps Twitter is taking today, that hack required nothing more than a teenager running the most elementary brute force trial-and-error script until the password "happiness" was found for the login at twitter.com/admin. But these steps were called for much more loudly none the less by the Twitter community after those hacks.

So Finally...Twitter Is Readying OAuth!

Twitter's proposed solution to making users all be "password-sluts" is a system called OAuth. It's an open user-authentication protocol based in large part on work done years ago at Flickr. If you've used an outside application for, say, uploading your photos to Flickr, you've seen how it works. You tell the application "my name is marshallk on Flickr and I want to use your service to access my account there." The service goes and asks Flickr for permission, Flickr pops up a window and says "this other website wants to access your private data on Flickr, can you prove you are really you and tell us to give them access?" Then you give Flickr your Flickr password, not the outside service.

The idea is that with OAuth, users can say to a website - "I'd like to bring my Twitter data over to your site, but let me log into Twitter and give them permission to give it to you."

Right now, outside websites are forced to essentially pretend to be you after cajoling your secret password out of you, tricking Twitter into giving up the data, and then promising you that they will not abuse this secret password knowledge they've been entrusted with.

It's a pretty unsustainable situation.

OAuth looks and feels to users a whole lot like the new Facebook Connect, or OpenID login. Why go with OAuth instead? Facebook Connect is a proprietary system that hoards all the user data over the long term and takes too much control over sites that use it. OpenID can't be used by desktop apps and is too often ugly enough that you'd rather stay home than take it to a party. Enter OAuth, a technology that hopes to solve all those problems.

By being an "open standard" it can essentially be replicated all around the web. That means that authenticating sites can just plug in a secure user login procedure with relative ease, and 3rd parties wanting to build a bridge between their apps and OAuth supporting apps don't have to build to a new data interface (API) every time, because there's a standard.

It doesn't always work perfectly. The Google-led OpenSocial initiative was supposed to herald a new day of data and application portability across scores of the social networks around the web (all the ones that are less popular than Facebook). Things like OAuth were supposed to make OpenSocial a "write once - apply everywhere" platform, but for political, technical and business reasons, it turned out much harder than that and almost no one cares anyway.

The Moral of the Story: Never Give Your Twitter Password to a Stranger Again

If the OAuth trial that started today is a success, you shouldn't ever have to wince and hand over your Twitter username and password to a stranger again. That will be very nice. It's the kind of thing that ought to be best practice everywhere that two applications swap spit (user data), and we hope it will be someday soon.

A key part of "data portability" will be letting users feel secure and in control enough of their data to go ahead and use it in multiple places. That's something Facebook has put a huge emphasis on, at the expense of open community standards and to the benefit of their business interests as the would-be only social networking game in town.

Announcing (?) The Twitter App Showcase

What's Twitter's plan for this surprisingly important technical direction they are exploring? We asked Twitter API lead Alex Payne and this is what he said:

My goal for our OAuth launch is to give our users more control and confidence in their interactions with third-party Twitter-powered applications. Basic Auth has worked for a certain class of single-user application running on a trusted network, but OAuth will increase the reach of Twitter apps that can be used safely and securely on a variety of platforms. What's more, OAuth gives us the data we need to build an application gallery to better showcase the great work Twitter developers are doing.

Our launch plan entails a month or two in private beta, a similar amount of time in public beta, and then a final release. After the final release, we'll allow OAuth to co-exist with Basic Auth for no less than six months, and hopefully not much longer. OAuth should be
the sole supported authentication mechanism for the Twitter API by the end of 2009.

Those are solid gold words, right there. We hope the OAuth community and Twitter can nail this test and implementation, opening the door to a new era of interfaces and applications built by anyone on earth but securely leveraging Twitter user data. A Twitter ecosystem where people feel secure sharing their data could end up being a much bigger Twitter ecosystem.

That should be not just be future of Twitter, that should be the future of data-centric online computing in every part of our lives.

And Then The Dominoes Fall

Many people say that Twitter is changing the web all around it. It's not just a symbol of a new communication paradigm, it's training millions of people to communicate publicly in very short, rapid messages.

That same influence could extend to helping spread secure, standards based user authentication protocols like OAuth.

Is isn't hard to imagine people saying "Twitter lets me use applications like Tweetdeck to send public messages to The_Real_Shaq - so why can't my bank data be shared with Mint without me giving Mint my bank password? Why can't my school transcripts be exposed to Netflix to get recommendations of the most popular movies related to the subjects I'm studying - without me giving Netflix my school password?"

That kind of future could come all the faster if all of these services used a standardized authentication system, like OAuth. As of this September, that's exactly what Netflix uses, in fact.

You get the picture. Effective Twitter implementation of OAuth is a far more important matter than it might seem. This isn't something small, dry and technical. This is the future of integrated, hyper-smart social computing being built right before our eyes.

Google will allow web services to join a limited test of an API based on the OpenID 2.0 protocol that will give Google Account users the option to sign in to websites with their Google credentials and without having to sign up for a new account at those sites.

Don't Mention OpenID

One of the key results of Yahoo's OpenID usability study was that users did not understand OpenID and what its logo stands for. Instead, Yahoo promoted the idea of giving users a sign-in button that simply said "Sign In with a Yahoo! ID" (though Chris Messina argues that this could be detrimental to OpenID in the long run).Google and its partners are taking a similar route and are basically bypassing any mention of OpenID itself in favor of a simple message saying "Sign in with a Google Account."

More to Come

Google also announced that it is looking to combine the OAuth and OpenID protocol so that a service can not only request a user's identity through OpenID, but also "request access to information available via OAuth-enabled APIs such as Google Data APIs as well as standard data formats such as Portable Contacts and OpenSocial REST APIs."

Tipping Point?

Thanks to this announcement, a wide range of some of the web's largest service providers now supports OpenID: Yahoo, Google, Microsoft, MySpace, and AOL.

As John McCrea notes, the result of these announcements from Google and Microsoft this week should be "a massive adoption wave for OpenID all over the web."

Today marks a significant step forward in bringing those plans to fruition as the Yahoo! Open Strategy (Y!OS) team officially throws open the gates to a newly rewired and open Yahoo!, providing developers with unprecedented access to Yahoo!'s network and social data.

What does this offering mean to developers? It means Yahoo! now provides the ability to "tap into benefits once only available within Yahoo!. Namely, you can leverage the content, traffic, and user base of Yahoo! to extend your presence on the Web."

According to Yahoo!:

"Most obvious will be the social aspects. At a high level, we're rolling out a social platform that will draw on the hundreds of millions of connections on Yahoo! - everything from random encounters with someone who commented on the same photo as you, to deep connections you have with friends who know nearly everything about you."

Specifically, developers gain access to the Yahoo! Application Platform (YAP) , Yahoo! Social Platform (YSP), and Yahoo! Query Language (YQL), a proprietary query language. All of the services are accessed via OAuth, a standard authentication protocol that - according to ReadWriteWeb's Marshall Kirkpatrick - is "a big ingredient in a recipe for innovation, in the form of mashups or otherwise."

Clearly, Yahoo! is hoping to benefit from the same types of "open API" strategies - outsourcing R&D as it were - that have helped Web 2.0 startups thrive in this new open era. And they've had a wealth of Web 2.0 talent at Yahoo! from whom they have learned - acquisitions like delicious, Flickr, MyBlogLog, and Upcoming, to name a few.

So where do we go from here? It seems that the sky is the limit. But one thing is for sure: by providing developers with access to the core Yahoo! set of functionality and allowing them to mix and match it with the variety of open data sources out there in the wild, things begin to get very interesting.

Interesting enough for Yahoo! to remain a viable entity? That remains to be seen.

As pointed out by intrepid explorer of the interwebs Chris Messina, there's now live code for OpenID authentication inside every MySpace user's profile. View the source on yours and you'll see it. This should be more than just single sign-on, too.

According to John McCrea's live-blogged coverage of the much needed OpenID/OAuth UX Summit this weekend, MySpace has some interesting plans up its big, teenaged sleeve. There Max Engel, MySpace's Product Manager of "Data Availability" said that the company will support OpenID, OAuth, and a hybrid of the two. They will use a pop-up iframe that allows the user to stay in context.

Does that imply that there will be OpenID and OAuth logins on MySpace for use with other OpenID providers' accounts? Or only that MySpace will give the world an iFrame the rest of us can use to login using our MySpace ID as an OpenID? Probably the latter, but maybe the former!

Either way, really, this is great news. Facebook Connect is making it easy for 3rd party websites to tie their users to Facebook authentication and friends lists, but MySpace has the opportunity to reach a different constituency and raise the bar on both how much user data is exposed to developer and how well it's protected for privacy-minded users.

We hope that the addition of OpenID code to MySpace profiles means we can see something exciting and new in production soon.

All parties involved in building the spec have signed a covenant of non-assertion, meaning that OAuth can now be safely implemented anywhere without concern about Intellectual Property lawsuits. If you think this is too geeky for you - try out the live demo embedded below.

The parties that contributed to building OAuth and have singed the promise not to sue are: Yahoo, Google, AOL, Twitter, Ma.gnolia, Citizen Agency, Wesabe, Pownce and Six Apart. Also signing as individuals were Eran Hammer-Lahav, Mark Atwood and Blaine Cook.

What is OAuth?

OAuth is a standard protocol for one web site to access user information on another website without asking the user for their password, but accepting confirmation from the 2nd site that the person is in fact who they claim to be. As Eran Hammer-Lahav, Open Web Evangelist at Yahoo! and OAuth point-man, told us tonight: "It is a way to build distributed services across multiple vendors while still keeping your data as private and safe as you would like it to be. You can limit it, for example - for time (like only one day), only read access, photos only and not videos, etc."

Why is this important? This is a key technical step towards making data portability real. It creates a path for users to move data they've created on one service into another service that can then offer new features or personalization based on what the users have exposed to them about themselves from elsewhere. It's a big ingredient in a recipe for innovation, in the form of mashups or otherwise.

How is it different than OpenID? It's a related, but different way to move data around. OpenID got a non-assertion covenant signed almost a year ago and provided, along with the Apache Foundation, the basis for the OAuth covenant. There's a whole lot that can be done with both of these protocols and we look forward to seeing them develop together.

What does OAuth look like in the wild? Below are two examples. The first is a screenshot of Yahoo's location based service Fire Eagle asking a user if they want to grant permission for another app to access their data on Fire Eagle.

Screenshot from Chris Messina.

The second example is a mock live demo of OAuth in an iframe, created by Eran Hammer-Lahav. A detailed explanation of this demo can found here.

Pretty awesome, no? So let's get the safe, granular data porting rolling! We eagerly anticipate a growing ecosystem of apps that do things with user data that were never possible before. As Eran Hammer-Lahav, who's been working on this full time at Yahoo! almost all year, says - the web owes him a beer.

]]>Discuss]]> http://www.readwriteweb.com/archives/oauth_nonassert.php http://www.readwriteweb.com/archives/oauth_nonassert.php News Tue, 26 Aug 2008 17:40:03 -0800 Marshall Kirkpatrick You can do a lot with new software if you tell it a little bit about yourself - but who wants to give the new kid on the block the password to their most important communication tools?

Unfortunately that's what we're asked to do with a lot of new applications these days. It doesn't have to be that way, though.

]]>Sponsor

]]> Standards based user authentication protocols, and one called OAuth in particular, allow applications to send you back to home base with a request for permission to access your data - whether that's your email contacts, your Twitter account or other information. Today we learned that Firefox is probably going to implement OAuth inside the browser itself and Twitter is getting ready to implement it for sure. That's very good news.

Twitter

Senior Software Engineer at Twitter Britt Selvitelle said today in a conversation for developers working with Firefox that Twitter "will be using OAuth as our primary form of token auth."

That's fantastic news for a few reasons. Twitter is a very important communication tool for many people, the service's Application Programming Interface (API) has allowed a huge ecosystem of interfaces and applications to flourish around it...and yet today all of those 3rd party apps have to ask for your Twitter password in order for you to use them. It's been an awful lot of risk for users to take and we're really surprised that no one has yet ripped Twitter passwords from unsuspecting users and then unleashed a wave of valid looking spam.

Finally, it appears, Twitter will soon implement a secure way for you to give 3rd parties access to parts of your account without giving them a copy of the key to walk in the front door any time they like.

Firefox

The conversation today took place in the context of a question from Matthew "lilmatt" Willis, a Flock employee and longtime contributor to Mozilla. Willis wants to know if the Firefox developer community would like OAuth built into Firefox and if so how. He points out that much of the work has already been done, if not multiple times.

We're not entirely sure what this would look like, but we are intrigued. Browser-based authentication for data mashups sounds great. Browser plug-ins that securely access your various accounts without asking you for your passwords sound great too.

As of this afternoon there's a developer preview of a browser-based OpenID implementation for Firefox (thanks Vidoop!) so we hope that an OAuth implementation for Firefox could be a complimentary project.

The Big Picture

Google adopted OAuth for all the Google Data APIs this summer, so there's really no reason why 3rd party apps should ask you for any Google passwords ever again.

This is all very good news for everyone. Secure user authentication equals greater user trust, which equals developer access to more user data. More developer access to user data equals more innovation. More innovation makes us happy (we love this stuff) and, co-incidentally, leads to more user data. Data portability is good for everyone. Bring it on, Twitter and Firefox!

]]>Discuss]]> http://www.readwriteweb.com/archives/mashups_firefox_may_go_oauth.php http://www.readwriteweb.com/archives/mashups_firefox_may_go_oauth.php Mashups Wed, 06 Aug 2008 16:17:26 -0800 Marshall Kirkpatrick Open source blogging platform WordPress may have won most peoples' hearts as the best blogging platform in town, but that doesn't mean its core developers are resting on their laurels. The company made two statements last night about moves its users are sure to love.

WordPress announced last night on the company blog that WordPress.com users have a new blogging option called "Turbo," which uses Google Gears to speed up the service's admin functionality. Just an hour earlier, WP founder Matt Mullenweg indicated that users should look for OAuth support in future versions of the software.

]]>Sponsor

]]> Gears

The new WP.com Turbo feature uses Google Gears to download more than 200 files to users' local computers so they can be run without accessing the web. Though many of the most high-profile Gears implementations elsewhere are focused on providing off-line functionality, it's not clear whether that's the case here or if Gears is just being used to speed up blogging. Either way, this is good news. With the new feature, WordPress.com effectively offers what is called a Rich Internet Application (RIA), combining the responsiveness of local actions on the desktop with the connectivity of the web.

RIAs are already shaping up to be a powerful part of the web. Local storage and user interaction with at least some data fleshes out the possibilities offered by the celebrated migration towards web applications.

This is probably only the beginning for WP support of Gears. We wonder whether the WP developer community will build extensions that leverage WP support of Gears, perhaps even incorporating Gears support for mobile devices. Oh, the possibilities are a thrill to consider. The draft version of WordPress.org, scheduled to be released in final form within the next two weeks, already includes support for Gears as well.

OAuth

OAuth is a user authentication protocol that is quickly becoming a standard. It's all about making mashups fast, easy, secure and thus more common. When Google rolled out OAuth support for all its data APIs earlier this week, we said it was only a matter of time until almost every one else did so as well.

WP's Matt Mullenweg said last night that he wants to see OAuth support in WP but wouldn't be able to include it in the next version. Can we expect to see it in the next version then? We certainly hope so.

What might OAuth support in WordPress look like? There are a number of directions it could go. By supporting inbound OAuth authentication, WordPress could do things like allow you to post to your blog through 3rd party applications without giving them your password. It could also allow blog commenters to associate their accounts on other OAuth supporting services with their WP comments, again without giving up their passwords.

For blog publishers to be able to get secure programmatic access to their reader's data from other services would be very exciting. You don't want to give some random blog your Google Accounts password, but imagine if you could see all the comments ever left on that blog by your Gmail contacts - without giving up your password. That would be great.

There are probably far more possibilities than we can imagine, but that's what makes WordPress so exciting. There's a huge world of plug-in developers that extend the service in ways that none of us could imagine. With OAuth support those developers would be able to leverage a whole new class of options based on secure user data. That means WP blogs could tie in programmatically with any of your Google accounts, your Photobucket account or any other service that supports OAuth in one direction or the other. That's exciting to imagine and it sounds like it should be coming soon.

We're excited to see that WordPress isn't just relying on its developer community to keep it fresh and hip with the times. These new core developments will serve as a foundation for those developers to improve even further on the WordPress user experience.

Automattic

]]>Discuss]]> http://www.readwriteweb.com/archives/wordpress_stays_hip_with_the_t.php http://www.readwriteweb.com/archives/wordpress_stays_hip_with_the_t.php Analysis Wed, 02 Jul 2008 08:57:52 -0800 Marshall Kirkpatrick Open standard based user authentication protocol oAuth has now been implemented across all Google Data APIs, quickly offering this young standard for easy mashups more market validation than it's ever had before.

Eight months ago we wrote about the launch of oAuth 1.0, asking if the standard would lead to a flood of mashups across the web.

]]>Sponsor

]]> A standard method of authenticating users across different services means that mashup builders need only write one authentication process, then apply it to all data sources that support the standard. That's hot, and it's now spreading faster around the web than we thought. We discuss what this means for users below.

Google's Support

Last night the Google Data API blog announced that oAuth is now available for all Google Data APIs, everything from Gmail contacts to Google Calendar to Docs to YouTube. This means that 3rd party app developers now have one easy, standardized and secure way to authenticate that their users really own the Google accounts they say they do - without the apps asking users for their Google passwords. That data from Google can then be mashed up with any other application interested in leveraging it.

Google had included oAuth into the OpenSocial framework, but there was little indication that app developers were making use of it. Google's recently launched FriendConnect offered website developers disappointingly little access to their users' data - partitioning the Google functionality into an iframe inside participating pages.

Other Support

We've wondered recently whether oAuth was just a good idea that wasn't really gaining any traction. The list of sites with live oAuth support has been much smaller than we hoped. Now that's changing fast. PhotoBucket offers oAuth support and today SmugMug announced it as well.

We expect to see oAuth authenticating and relying parties spring up all around the web now that coveted Google user data is available through oAuth.

What This Means for Users

There is now no good reason for new applications to ask you for your Gmail username and password in order to access your list of contacts. Don't give it to them - there's a standard, approved way for them to access that data now that doesn't require giving them unlimited access to your entire account.

Apps that don't use the approved Google user authentication method in short order will be acting like a mail carrier who says they have to have a key to the inside of your house to pick up your mail because they aren't familiar with the mailbox on the front porch.

Furthermore, we as users can now expect a thrilling new wave of mashup options that can take secure advantage of our Google data. Google's adoption of oAuth is one of the most significant, tangible moves in support of authentic data portability that we've seen in a long time. App developers should be tripping over each other to make use of this data so that our use of their apps can be made richer, more powerfully useful and engaging. While they are developing to take advantage of Google's oAuth APIs, why not offer some oAuth back out to the world as well? Google's validation of the standard should start a snowball of standards enabled mashups.

We're very excited that Google has taken this step to un-silo our data and support the mutually beneficial ecosystem of mashup developers and users. We're very happy too for the community of oAuth supporters, who have done a great job building and spreading something so needed around the web. Today is a good day for the future of the web.

]]>Discuss]]> http://www.readwriteweb.com/archives/google_oauth.php http://www.readwriteweb.com/archives/google_oauth.php Mashups Fri, 27 Jun 2008 11:31:55 -0800 Marshall Kirkpatrick The Get Satisfaction API that we reported on in February was finally released today. Two months ago, Get Satisfaction said they were "superclose" to releasing the API -- perhaps not so close as they thought. However, the company today announced the release of that API with the goal "to expose every part of the Get Satisfaction service." Get ready: the customer support mashups are coming!

]]>Sponsor

]]> Get Satisfaction is a consumer web service that allows users to discuss complaints, problems, and ideas about any product, service, or company. Users can support one another, band together to indicate a common problem or need, and companies are invited to join in and give "official" responses to users on the site. Get Satisfaction is a great idea, and many companies are already participating, including some big ones like Google, Yahoo!, and Microsoft.

The API will allow companies to build services on top of the Get Satisfaction infrastructure. As president Lane Becker suggests, a company could recreate their Get Satisfaction area on their own site, or they could build widgets to expose their support channels to readers on the company blog, or the social networking profiles of employees. "Or create some clever visualizations that help you better understand what your customers are saying," writes Becker.

On the consumer end, the API could be used to create tools that make it easier for people to create and track discussions around companies and products. We think it might be interesting for someone to create a mashup that tracks which companies are the most talked about on the site, as well as the overall mood of each (i.e., which company has the most optimistic customers? the most frustrated?).

The Get Satisfaction crew has released Ruby and PHP libraries for the API, which are available on the new, Mashery-hosted developer site. The API also supports OAuth, a third party identification protocol that will make it easy for companies to integrate Get Satisfaction services into their existing user ID system by passing users into the Get Satisfaction system and automatically creating/linking accounts there.

In a blog post, Becker promised additional "API-related tricks ... in the coming weeks and months" from Get Satisfaction.

]]>Discuss]]> http://www.readwriteweb.com/archives/get_satisfaction_api_lands.php http://www.readwriteweb.com/archives/get_satisfaction_api_lands.php Products Wed, 16 Apr 2008 18:51:31 -0800 Josh Catone