Hueniverse

Explaining the OAuth Session Fixation Attack

There is a pretty good story behind this. That is, how we found and managed the OAuth protocol security threat identified last week. In many ways, the story is much more important and interesting than the actual technical details of the exploit.

For everyone involved, this was a first-of-a-kind experience: managing a specification security hole (as opposed to a software bug) in an open specification, with an open community, and no clear governance model. Where do you even begin?

But right now, I know you want the technical details.

Introducing 'Sign-in with Twitter', OAuth-Style "Connect"

Yesterday Twitter released 'Sign-in with Twitter', the ability to use Twitter as a delegated sign-in provider for third-party websites. The cool thing about this new feature, which is part of their OAuth API beta, is that it is completely standard OAuth. No extensions, not secret sauce, and not another proprietary provider (yes, I'm looking at you Facebook).

It is Open done right.

With this small enhancement of the Twitter OAuth API, Twitter created a product that directly competes with Facebook Connect. The implementation details are significantly different (and there are some technical shortcoming on both sides), but there is little you can do with one and not the other. There is no reason why 'Sign-in with Twitter' cannot be used anywhere Facebook Connect is offered, including blog posts and activity streaming.

On Versioning Specifications

With a growing number of new specifications being published by first-time authors, I think it is important to pay attention to when should a specification carry a version number. For most people, giving a specification a version is a sign of forward thinking and planning for future revisions. But not every specification should have a version number.

OAuth Nominated for CNET's Webware 100 Awards

 OAuth was selected as a finalist in the Infrastructure & Storage category in the 2009 Webware 100 Awards. I consider this nomination as a recognition of the incredible accomplishments of the OAuth community and the record-breaking adoption of the OAuth Core 1.0 protocol. Voting is open until April 30th, so go vote...

Clarifying OAuth Requirements for Service Providers

Its never good when specifications are read like the bible, where people find in it what they want.

Over the past few months I have been getting many questions about requirements in the OAuth Core 1.0 specification, as well as finding significant issues with existing implementations. I agree that the specification isn't clear on many of these issues, but until we have a replacement, I hope this list would help.

Internet Identity Workshop, the Identity Geekfest

There are few events more productive than Internet Identity Workshop.

And few that I enjoy quite so much. I'm an engineer at heart, even though these I play a pseudo-lawyer and write specifications. While I enjoy the meta conversations about the social web, I love talking code. The real thing, like working with a group of people on a new XML schema using a whiteboard, or walking through use cases and designing protocols. Ultra-geek stuff.

Report from the OAuth BoF at the IETF 74th Meeting

The OAuth BoF at the 74th IETF meeting was such a success, it ended early after the chairs had nothing more to say, and with applause from the audience. Later people went out of their way to tell me just how unusual the reception OAuth received was. Turns out it is actually hard to get stuff accepted for standardization in the IETF (or so I was told).

The meeting agenda included two main items: discussion of the charter status, and an overview of the specification draft current status. The idea was to start a list which will turn into our issues list once work officially begins.

More Thoughts on OAuth Access Sharing

(Or, About Secondary Tokens)

In response to my previous post on taking OAuth beyond the 3rd leg, Mike Malone reiterated the point that while these ideas are still better than sharing passwords, they take away much of the security offered by OAuth in the first place. I agree. But the trick is to find a solution that is consistent with the simplicity of the OAuth protocol design. If it is not easy to implement, it is not likely to be used.

Mike suggested to allow applications to request a much more limited token for sharing, with limitations on scope, number of requests, or lifetime. I like this idea, a lot, but the difficulty is to find the right balance of restrictions and usability.

For example, limiting scope might not work with access sharing among applications that need a high degree of access. Lifetime limiting will not allow access sharing with background applications. However, here are some ways to implement this without getting too complicated. Again, these are just ideas and need to be further developed.

Taking OAuth Beyond the 3rd Leg

(Or, Delegating Delegation)

There is nothing like a popular API to drive OAuth forward. As more developers transition to use Twitter's new OAuth API, new requirements emerge. Existing sites based on Twitter use Twitter usernames and passwords for more than just calling the Twitter API. They use it as a sign-in solution for their own service, as well as to integrate with other Twitter-based applications.

There are many cases in which one third-party application uses functionality from another third-party application. For example, my iPhone Twitter client Twittelator, integrates with TwitPic to allow me to post photos directly from my phone. The way it works is that Twittelator has my Twitter username and password, and TwitPic uses the same credentials to offer its service.

When I gave Twittelator my Twitter credentials, I implicitly allowed it to act on my behalf without limitations. Everything my Twitter credentials can do, is technically fair game for this third-party application. Of course, applications should never abuse this power, but as long as they deliver expected results and don't scare their users, people will be happy with the additional functionality.

Once Twittelator or TwitPic switches over to the OAuth API, this functionality breaks.

XRD-Based OAuth Discovery Sneak-Peek

The new approach to OAuth discovery centers around the introduction the OAuth Provider. The OAuth Provider is the resource whose descriptor provides all the information needed to interact with the server and obtain a set of client and token credentials.

Find the OAuth Provider descriptor and you have everything you need. Please keep in mind that this is just an initial outline and that no code should be written yet according to this example.

Let's jump right in...

Setting the Stage for the New OAuth Discovery Protocol

If you like the new direction discovery is taking, you can give the credit to the original work on OAuth discovery. My first attempt at defining a discovery framework for OAuth over a year ago was a highly complex spec that confused more than it helped. But it identified the need for a simpler profile of XRDS, and so, the second draft of OAuth discovery introduced XRDS-Simple.

Problem was, while it was simpler, it wasn't simple.

The work on XRDS-Simple exposed some basic flaws in the overall architecture. These are being addressed head-on with XRD. Yesterday I started sharing how the new discovery framework can be applied to OpenID. Now it's time to take a look at the original use case: OAuth.

OAuth Core 1.0 Reborn

First, a few disclaimers. This is the unofficial work of a single individual (me), not a community endorsed specification. While it is a significant improvement over the official OAuth Core 1.0 specification (if I may say so myself), there is only one OAuth Core 1.0 specification, and until decided otherwise by a strong community consensus, it will remain the only one. And last, this revision was designed as a purely editorial rewrite of the specification. It should not change how the protocol works in any way (except for a few bug fixes which were discussed and agreed to by the community).

Now that I got that out of the way...

I am excited to announce and share the publication of the unofficial OAuth Core 1.0 "Editor's Cut" edition (you know, like they do with movies). This is what OAuth would have looked like if I had 2 years of specification writing experience prior to writing the original specification (editorially speaking).

As important, this "Editor's Cut" edition comes complete with a shiny new "Messina's Cut" logo version (equally unofficial). Special thanks to Chris Messina for the special edition logo.

Sunday Morning Homework

(Or, Refreshing Your OAuth Knowledge)

As we are getting ready to work on the next version of OAuth, focused on security and interoperability, it is time to refresh your knowledge of protocol and its design principals. Over the past few days I went back to the OAuth guides to draw ideas for my rewrite of the Core 1.0 specification. I'm trying to produce a purely editorial revision, writing a better specification without making any changes to the meaning of the previous normative text. Something like an unofficial Second Edition.

So if it has been a while since you last read the specification, wrote code, or read the guides, now is the time to refresh...

State of the (OAuth) Union

OAuth Core 1.0 was declared as final specification almost a year and a half ago. The overall reception was incredible with almost overnight adoption from major web players like Google, Yahoo, and MySpace. We even got the attention of the major internet standard bodies, approaching us, some officially, some less so, to bring the work over. It has been a good year for community-driven specifications with OAuth leading the charge.

During the past year, we've also seen a lot of new ideas and new requirements coming up. Most people are not aware that there are about 15 proposed extensions for OAuth covering a wide range of topics. There is also a lot of confusion regarding what is going on with the specification, how should extension be proposed (and made "official"), and recent announcements.

This post will try to answer some of the questions I receive from people on a daily basis. If you care about OAuth, implemented it or plan to, or have any dependency on the specification, technology, or community, this should be a helpful read. If I missed an important question, please let me know in the comments.

• What's Up?
• What is the Status of OAuth Core 1.0?
• Is there a New Version Coming?
• What is Being Done to Make the Current Specification Easier to Read?
• Is OAuth Moving to the IETF?
• Why the IETF?
• Why does the IETF want OAuth?
• Who Made You In Charge (to Bring OAuth to the IETF)?
• Why isn't the Current Specification Good Enough? Why Seek a Standard?
• OAuth doesn't Address My Use Case, How can I Extend it?
• Any Upcoming OAuth Events?

Beyond the OAuth Web Redirection Flow

(Or, How Do I Make My Desktop Applications Usable with OAuth)

There are plenty of reasons why the OAuth web redirection flow sucks. That is, the flow described in section 6 of the OAuth Core 1.0 specification. And it was all said before: it smells like phishing, it can be slow, it is hard to relay errors to the user, potential for high drop off rate, unfamiliar pattern for end users, difficulty in balancing security warnings with practical usability, requires a browser, and on and on.

But none of these are reasons not to use OAuth. They are simply challenges to overcome and a call for action to find new and better ways to authenticate users and authorize access on the web. Yes, this is a huge undertaking, but there are plenty of ways site owners can improve it today and still support OAuth. In the previous post I talked about some of the limitations of OAuth with a desktop client and the rules of rolling out an OAuth API. Now it's time for some ideas moving forward.

Should Twitter Discontinue Their Basic Auth API?

(Or, The Challenges of Using OAuth in Desktop or iPhone Applications)

 Services adopting or considering OAuth like Twitter, face the question of how to get developers to move from their HTTP Basic Auth API to their OAuth API. If you keep both, why would anyone bother to learn a much more complex authentication method and subject their users to a workflow where at least some will drop off. And let's not forget that services can always ignore the API and use screen scraping like in the "good old days" if you make it too hard.

Dumping the problem on your API developers (or worse, your users) isn't going to help anyone.

Prologue (to Open)

2009 is going to be a big year with a lot of exciting things coming.

OAuth is going to be worked on at the IETF. Discovery is finally going to be specified and deployed using critical building blocks such as Link, Host-Meta, XRD, and LARD. The Open Web Foundation will publish a new license that will empower developers to author and use community specifications. Standards will be created in new and improved ways.

I would like to spend some time discussing the guiding principles of these objectives. We take too much for granted and ignore the fact that many of us in these communities are on conflicting paths and agendas. There is nothing wrong with that but it is important we understood the ways in which we differ.

In the next few blog posts I will define what Open means to me, explain what is the Equal Access Principal, discuss why OpenID is so significant to the future of the Open Web and why it is time for it to move aside, and I will outline a roadmap for how we should evolve the tools we have been focusing on into something completely different.

Beginner’s Guide to OAuth – Part IV: Signing Requests

Time to put the previously discussed concepts into action. The following explanation is designed as an interactive walkthrough with customizable inputs. Next to each set of inputs you will find an expand [+] icon allowing you to change the example and see how such changes affect the intermediate and final results. To expand the forms, click on the [+] icons which will open the form or click again to collapse. Making changes to the pre-filled values will immediately change the walkthrough content. You can also adjust the default values the example starts with by choosing from one of the pre-configured use cases. This post cannot be viewed in a feed reader.

Beginner’s Guide to OAuth – Part III : Security Architecture

As an authorization delegation protocol, OAuth must be secure and allow the Service Provider to trust the Consumer and validate the credential provided to gain access. To accomplish that, OAuth defines a method for validating the authenticity of HTTP requests. This method is called Signing Requests and in order to understand it, we must first explore the security features and architecture of the protocol, which will be the focus of this part of the Beginner's Guide. In the following part we will explore how all this comes together and translates into the OAuth signature workflow using interactive examples. The examples in this post cannot be viewed in a feed reader.

OAuth Presentation at Open Hack Day

I gave a quick introduction to OAuth recently at Yahoo!'s Open Hack Day. It is directly based on my Beginners' Guide to OAuth with slightly improved graphics. The PowerPoint file is available for download as well and contains additional comments and explanations in the notes over at SlideShare.

OAuth for Cars

My car doesn't have a valet key but it does support OAuth.

Ok, I might have gone a little overboard...

OAuth Licensed, a Step on the Way to the Open Web

Specification are tricky creatures. On their own, they are only copyrightable. But on their own they are also not very interesting. Their value is in their implementations, and those are subject to patents. If you have been following the tech world over the past couple of year, you know that patents can be very risky to developers. The problem is that in order to implement specifications, the developer usually has to write code that uses some existing patents. It is practically impossible to know which patents are involved, but at a minimum, the developers need to know that the people who wrote the specification are not going to sue them.

I CAN HAD OPEN: OAuth First Summit a Hit!

The first OAuth Summit hosted by Yahoo! last week was a huge success. Fifty (!) OAuth community members attended representing 20 companies, large and small, as well as a couple dedicated individuals. The list of companies represented at the summit is extremely gratifying to see considering the fact that OAuth started and still is a community-driven effort: Agree2, AOL, BroadOn, Bubble Labs, Eye-Fi, Facebook, Garmin, Google, LinkedIn, Ma.gnolia, Microsoft, MySpace, Plaxo, Pownce, SafeMashups, Salesforce, Songbird, Veodia, Vidoop,  and Yahoo!.

I CAN HAS OPEN: OAuth Summit 2008

Everyone is talking about Open these days, and it is a very exciting kind of Open. It is the Open that allows developers to utilize the best resources available online and combine them into new and innovative products and experiences. The internet has always maintained a healthy balance allowing users to pick and choose the individual services that suit their needs. What this new Open adds, is the ability to allow new providers to build on top of the existing layer and improve it, rather than have to start from scratch. It also enables users to get more out of their existing online presence, making their digital assets do more for them.

OAuth, a community-driven open standard was designed to address sharing of resources between services while maintaining full user ownership and privacy. We are all too accustomed by now to being asked for our username and password when joining a new service in order to import our existing data. The obvious problem is that the credentials we are asked to share control more than just our address book, photos, or bookmarks – they often control our electronic wallet, confidential correspondence, financial and medical records, and other sensitive data. To make things worse, sharing our email username and password means granting full access to almost everything we do online on other sites since email is the most common way to change and recover passwords.

OAuth Discovery Draft 2 Released with Vendors Support

It’s always gratifying to announce new specifications or new drafts of existing efforts. OAuth Discovery has been in development for over five months and has matured a great deal since its initial introduction at the Internet Identity Workshop. I am happy to announce the availability of the OAuth Discovery 1.0 Draft 2 specification which is also the first implementation of the recently announced XRDS-Simple format.

What makes this announcement significant is that the new draft is already implemented and deployed by FireEagle (a Yahoo! Brickhouse service), Ma.gnolia, and Get Satisfaction – three leaders in the OAuth community. On the development tools front, Mediamatic will release initial support for discovery early next week with full support due early May in their OAuth PHP library.

         

The War of the Ose’s

OAuth 1.0 and OpenID 2.0 went final one day apart. Each has a very well defined purpose and were designed to work well with each other. OAuth’s primary focus was a way to delegate authorization, mostly in the realm of APIs; and OpenID creates a distributed identity service. When put together, OAuth allows users to use their OpenID with widgets and other services, and that was one of the initial driving forces behind developing OAuth. For the most part, each protocol does its thing well, and plays well with its counterpart. But from a technology standpoint, we made a bit of a mess.

A Way Out of Cheating

Nouncer is a web service, and that all it is. Nouncer is not a web site, as in a destination people go to interact and get information. It has no human accessible pages and is only useful for developers building their own solutions. Of course, it is not the only or first of such facility, but it is unique in that it is trying to use OpenID and OAuth without actually offering any user interface.

The problem is, that both protocols require some level of user interaction, if it is to capture their credentials or request their approval. The challenge is to offer an API that is truly customizable while still using open identity technologies. I have found my way to OAuth when I realized that my plan to use OpenID for Nouncer wasn’t trivial. There was no API way of handing over your OpenID the way you do with HTTP Basic authentication. OAuth solves that.

But still, both protocols are not yet ready for a scenario in which the service provider does not wish to interact with the end user at all. Not even a little bit. Ideally, all this will be done by someone else such as the consumer (the site using Nouncer to build their own site) or the OpenID provider.

Where are Your Endpoints?

Chris made his list of companies who should have deployed OpenID by now. I am not going to list everyone who promised to come out with OAuth just yet, but I will. It is enough to look at the OAuth Core 1.0 authors and the companies they represent to see that we have a long way to go. Of course Hueniverse’ own Nouncer supports OAuth, and even OAuth Discovery. But some might say this is not really fair, as Nouncer is still in development. So take a look at Ma.gnolia, they had the first working OAuth Core service in production, and had Discovery deployed within hours of draft 1. So go, do!

Being Two-Legged in a Three-Legged World

Google caused some confusion when they announced OpenSocial will only use some parts of OAuth, and with a few minor adjustments. While the language of the announcement could have been a little clearer, it described a unique OpenSocial need: authenticate Consumers when no user interaction is needed. In the OpenSocial world, when a user installs a widget, they automatically grant Consumer access to their resources. So the OAuth dance of getting the user to agree is not needed (at least in the context of accessing containers).

It’s About (OAuth) Discovery

I’m happy to announce the publication of the OAuth Discovery 1.0 specification first draft. OAuth Discovery enables partial and full automation of the OAuth protocol by using a machine-readable OAuth configuration documents. What is even more exciting is that we already have two Service Provider implementations available for Nouncer and Ma.gnolia, upcoming support from Twitter, and are expecting a Consumer library and test server soon. As with any first draft, the specification is expected to change and feedback is highly appreciated.

It’s Here – OAuth Core 1.0 Goes Final

I’m excited to announce that the OAuth Core 1.0 specification has been released today as final. It has been a great (and surprisingly short) adventure working with great minds to create a specification that will make the web a better place for users and developers. I will post the third part of my on-going Beginners Guide to OAuth in the coming days. But the OAuth work is far from finished. We now have to get some critical extensions out, like signing of HTTP bodies, discovery (which I have started implementing for Nouncer at http://api.nouncer.com/.xrds), additional signature methods, and better integration of OAuth with OpenID.

Congrats to everyone involved and thanks for letting me be part of this.

Upcoming Events

Tomorrow (11/28), I will be at New York’s first MatchupCamp, an event I am helping to organize. MatchupCamp is matchmaking for startups. It is a unique networking events for those with an itch to join or start a tech startup in the New York area. Organized by nextNY, MatchupCamp is all about sharing ideas and skills in hopes to make some useful connections. There are many networking events in NY, but none focused on those ready to get their hands dirty and build something new. If you are in town, come and check it out. If you want to talk about Nouncer and the positions available, please find me there (or drop me a line).

I will be at Internet Identity Workshop next week in Mountain View, CA (12/3-5). It will OAuth’s primetime among many other great ideas and technologies. We plan to make OAuth Core 1.0 final and release it to the world. If you haven’t been keeping up, we’ve recently published OAuth Core 1.0 Draft 7 which is very stable and has a growing developer community and code libraries. Nouncer’s OAuth endpoint are due this week in the new alpha environment.

OAuth: The Podcast

Larry, Chris, and I spent an interesting hour talking about OAuth to the guys at Bungee Connect for their Developer Network. The conversation gives some background on the history behind the protocol, the problems it was set to solve, and a bit of advice for getting started. We talked about what is needed to make OAuth a success, and how it is relevant to today’s web.

OAuth End-User Experience Demo

This quick demo is useful for explaining what OAuth looks like to the end user. It is fully explained in the beginner's guide but I find it very useful in this interactive format.

To use it in your own blog or site, use the following HTML code:

<iframe src="http://nouncer.com/oauth/flow-demo.htm" height="382px" width="484px" scrolling="no" frameborder="no"/>

Beginner’s Guide to OAuth – Part II : Protocol Workflow

OAuth is best explained with real-life examples. The specification includes in Appendix A a similar example but focuses on the HTTP calls syntax. This walkthrough demonstrates a typical OAuth session and includes the perspectives of the User, Consumer, and Service Provider. The websites and people mentioned are fictional. The Scottish references are real. And so our story begins...

OpenID Makes Close Better

With the completion of OAuth Core 1.0, it was time to go back to what I was doing before – getting the Nouncer API ready. Like others, my interest in OAuth started with the plan to use OpenID as the user credential platform for the API. Now that OAuth is ready, I am going back to my initial objective of integrating the two (something I plan to write about in an upcoming post). Given that Nouncer is taking shape as a corporate solution rather than a consumer service, I’ve started questioning the need for OpenID. After all, it is not something you’d think about when discussing closed internal corporate identity systems.

Beginner’s Guide to OAuth – Part I: Overview

With OAuth reaching its final draft (OAuth Core 1.0 Draft 4) last night, it is time for those of you new to the protocol to dive in and learn what it is all about. I have written in a previous post about the history behind OAuth, its use cases, and when it is (or isn’t) applicable. People seems to like my metaphor of a valet key, which John Panzer rephrased “OAuth: Your valet key for the Web”. This post is for those wishing to understand the internal mechanism of the protocol, and go beyond the introductory Explaining OAuth post. This guide assumes you have already read Explaining OAuth but not necessarily the specification. This guide is first posted here to solicit feedback and will eventually make its way to the official OAuth Community website.

Beginner’s Guide to OAuth – Part I

Introduction

This guide is intended for a technical audience with focus on implementation. I dedicate one section to the end-user perspective which is something I expect many others will address with mockups, user interface designs, best practices guides, and of course working services. To make the most out of this guide, keep the specification handy as I will be referencing it, walking you through the spec and adding color where needed. This guide does not replace the specification nor can it be used alone for implementation as it is incomplete.

OAuth Authentication 1.0 Draft 2 Released

I am glad to announce that the OAuth Authentication 1.0 Draft 2 has been released a few minutes ago. It includes many small fixes to make it read better, and a few more significant changes such as RSA support and a new Security Considerations appendix. We also added easier navigation and section numbers to make it easier to use. We will be listening to your feedback over the next 5 days and release the final specification, or publish Draft 3 if needed.

OAuth 1.0 Public Draft Released

The OAuth specification went through some significant rewrites over the past few weeks and is now, finally, ready for public review. Draft 1 has been posted today, with a planned Draft 2 next week and a final version October 1st. If you have been reading the spec over the past few months, you’ll notice that the workflow has been unified for websites, desktop applications, and mobile devices. We also simplified the signature process and added implementation details. The spec now includes a complete example from beginning to end.

OAuth Needs Karl Rove

I said before that only Karl Rove can fix phishing attacks and internet security problems that are caused by users laziness and carelessness. We need the man who got George Bush re-elected on a platform of fear. OAuth will provide a (much) better way to share your stuff without sharing your password, but it doesn’t replace passwords.

Even with OAuth, we need to scare people into being more careful and smarter about what they do online. To prove my point: Flickr, Google, and others have great (but proprietary) OAuth like protocols, but sites still ask for your Flickr and Google passwords and you still give it to them. It takes a while before I share my password from one site with another because I don’t trust them.

I Shall Call You Squishy

Let see if I can confuse you a little bit. OAuth, pronounced “Oh Auth”, started as OpenAuth – OpenID’s party-loving cousin. AOL came and took OpenAuth for their own API protocol. It then changed to Oauth pronounced like “Oath” until Pownce’s Leah Culver talked everyone into the current pronunciation (or so the legend goes). Now, OAuth has nothing to do with OATH, the Initiative for Open Authentication over at OpenAuthentication. And if an Israeli tries to explain OAuth to you calling it “Oh Oaf”, don’t take it personally.

OAuth isn’t (Always) the Solution

Don’t get we wrong, OAuth is great, or at least I hope it will be considering the number of hours I put in this week into getting the spec ready for prime time. But I’ve been hearing a lot of chatter lately on what OAuth is good for and some of it makes little sense to me. I don’t want to point at specific examples as some of them come from people I truly admire, but they are there. At the Data Sharing Summit, OAuth was thrown into the mix of solutions to problems it had nothing to do with.

OAuth Therapy

This is the first of our new occasional geek humor cartoons. They are all meant to be funny to a small group of people in the know, which in a way makes them even funnier. Of course I cannot draw if my life depended on it – I just write the concept and other talented people bring them to life. ‘OAuth Therapy’ was created by Christopher Carrasco.

Would You Like Some Quechup with Your Phish & Chips?

Public comments about OAuth are a great opportunity to explain the thinking and goals behind the protocol. Rob Sayre asks about the protocol use of redirection in order to get the user to grant access:

“Maybe I’m missing something, but doesn’t this train users to enter their credentials into web pages they’ve been redirected to?”

First, you are correct. Redirection carries with it some risk of training users to follow a pattern of coming to a login screen without explicitly entering a URL in the browser address box. The basic idea behind phishing is getting the user to a page they think is one thing but is really something else. A link in an email message made to look like your bank is actually a fake page asking you to enter your username and password. When you fall for it, it usually redirects you back to the real bank to enter it again (making you think you just mistyped).

Explaining OAuth

Update: For the most recent information about OAuth, subscribe to this blog or check out recent OAuth posts. The technical information in this post is outdated and based on old drafts. It does not represents correctly how OAuth works. Instead, check out the Beginner's Guide to OAuth.

*  *  *

With OAuth 1.0 Draft due out next week, I wanted to introduce the protocol and try to help people understand what it is and what it is trying to solve. OAuth (pronounced "Oh Auth") is mentioned is many blog posts, usually in the context of OpenID and Open Social Networks. While OAuth can play an important role in helping open up closed communities, it is not specific to social networks. The short(est) explanation of OAuth is ‘An API access delegation protocol’. Now for the longer one.

In the Works

It has been a busy couple of weeks.

I've been focused on implementing the Nouncer API. As luck would have it, exactly when I was looking for an API session authentication solution, a bunch of smart people were busy working on exactly that. Initiated by Twitter’s Blaine Cook and Citizen Agency’s Chris Messina, the group have been working on the OAuth protocol (site coming soon) for almost a year and it is due for release next week.

OAuth (pronounced “Oh Auth”) is an API authority delegation protocol – it allows you to grant access to your private resources (such as your Twitter status, Flickr photos, etc.) to 3rd party applications (i.e. Twittervision) without sharing your password with them. OAuth builds on existing protocols (Google AuthSub, Yahoo BBAuth, AOL OpenAuth, etc.) and attempts to create a single open standard that will be able to replace all the proprietary stuff out there and establish a common language for developers to implement.

While you wait for Nouncer, here is something to keep you busy.

In the next two weeks Hueniverse is going to release a new Facebook Application called JabAbout. It is a new social game that came about while working on the Nouncer platform. Once you start playing with the idea of micro-blogging and what can be done with the tool, it is hard to stop.

JabAbout is a byproduct of Nouncer, but one that does not fit with the framework itself. Instead of making it another service, I decide it would fit right in as a Facebook application. It is wickedly simple and I think can be a really fun game to play. My plan is to add it to my profile on Facebook and invite my friends (I will also mention it here when its ready). I want to see how fast it will spread just from one source. If you want to be included in the initial launch request to add me to your Facebook profile. More on JabAbout soon.

Elements of API Security

Pownce’s API chief Shawn Allen recently opened a Google group to discuss the upcoming Pownce public API trying to capture the same community buy-in the Twitter group is known for. Shawn raised the question of API security and authentication, something  I have been thinking about for a couple of months now (building a somewhat similar service). The goal is to try and find the right balance between ease of use for developers, security and privacy. Nouncer requires a solution that will address multiple client needs (desktop application, AJAX script, server-side web script), and will be easy to use in multiple technologies. This message was originally posted to the Pownce API group and has been revised for the Hueniverse blog.