Twitter Development: What are Data Portability and OAuth?

This article is excerpted from Chapter 6: Basic Authentication and OAuth of the Wrox book, Professional Twitter Development: With Examples in .NET 3.5, by Daniel Crenna, and is reused by permission of the publisher. This may not be reused without publisher permission.

Twitter Development: What are Data Portability and OAuth?
What Is Data Portability?
With the explosion of social sites and services online, a growing concern among heavy users of these kinds of applications, and the developers behind them, has centered on the safety of a user’s content and credentials across a multitude of sites, as well as the reusability of user-generated content at each provider site. This spirit of portability has benefits for the user and the provider; if I sign up for a photo-sharing service and upload my entire family album, if that site participates in the technologies and formats of the open web, then I don’t need to upload those same photos to another service just to make use of a few features I find compelling. Similarly, if my user-generated data is available to other applications, then I can log in to a service I haven’t used in a few months and it is up to date and ready for me, as if I had kept up my activities on the site all along. This is all thanks to the ability to grant applications access to my updated content. One resource available to you to research and get involved in technologies that support data portability is http://dataportability.org, as shown in Figure 6-1. This site, and others similar to it, is attempting to spread awareness of technologies and micro-formats that help promote an open web, and protect the users who rely on your applications to enrich their web experience.

Figure 6-1:  http://dataportability.org
For the purposes of building Twitter applications, your focus on data portability is more to protect the credentials of your user, who may use several Twitter applications. Whenever a username and password is compromised, either from a malicious Twitter application or through hacking an application using Basic authentication, it unlocks that user’s privileges for all the Twitter applications they may use. Your applications, however, can become part of the solution by using OAuth, Twitter’s preferred authentication scheme for protecting user credentials over HTTP.

What Is OAuth?
One of the recognized technologies in the data portability movement, according to its own site at http://oauth.net, is billed as “An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.” The authors of the specifications include developers from well-known social players, past and present, such as Twitter, Google, Flickr, Six Apart, Jaiku, ma.gnolia, and Pownce. These developers came together to find a way to solve the problem of desiring inexpensive and open access to developer APIs that enable you to write applications that bring together features from multiple social services, while maximizing the protection of user credentials and resources from malicious hackers and application developers.
User Credentials are Hidden
A user’s username and password credentials are never shared with the OAuth consumer, which means that a hacker cannot infer a user’s credentials from any of the information provided in a request. Instead, a representative signature derived from specific parameters on the request as well as shared secret keys between the consumer and publisher is sent with each request to verify the request is legitimate.
Credentials are Not Reusable
OAuth employs cryptographic hashing, nonce values, and timestamps to ensure that a prepared set of OAuth credentials is only used for a specific request at a specific time. One of the key benefits of building time sensitivity into signatures is avoiding a replay attack, where a malicious observer watches an OAuth request reach a server successfully, and then attempts to send the same credentials with their own request to impersonate the user; a nonce is only usable one time, and timestamps allow the server to compare an incoming request to see if there is enough latency to determine it was not created by the original author.
Credentials are Two-Way
When an OAuth consumer, such as your application, subscribes to a publisher site such as Twitter, a consumer key and secret is issued that specifically identifies your application as the intended custodian for user privileges when they are authorized. This means the credentials provided in an OAuth request are inextricably linked to your application, and cannot be used to access any other application. This linking of consumer and publisher helps the unauthorized use of user credentials if compromised, and also makes it easy to change the key and secret values used to identify your application—should those details find their way into the wrong hands—without causing service outages for your existing users.

To be continued…  See article, "The OAuth Specification"

Tags:

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *