There has been a lot of discussion lately around Twitter's use of OAuth. I had added a post around earlier around the countdown to OAuth. Now that the Twitter apps are forced to use OAuth, new issues and complains are popping up.
A post by Ryan Paul has attracted a lot of attention in his recent post around OAuth.
A lot of issues that he mentions could be attributed to Twitter's implementation of OAuth rather than generic OAuth itself. However one core issue that he brings up is around suitability of OAuth for desktop applications. The OAuth version 1.0a happens to be the latest version of the specification. I was under impression that OAuth 1.0a was meant to be used for web applications only. This is because the specification in general is pretty vague around use with desktop apps. However when I checked again, it does say clearly mentions this upfront: "OAuth is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications." desktop applications? Really?? I just think it is an overstatement to claim that OAuth is suitable for desktop oe mobile apps. Let's look at why it is not make it ideal to use for native app.
Credential Management Issues:
The API caller needs to identify itself by specifying who I am. That who I am is basically its OAuth credential (combination of consumer key and consumer secret). So in this case, this desktop and mobile app will need to have its own credentials that it needs to use. This credential management poses a couple of interesting challenges.
First, how does app gets its credentials? Is this something that app is shipped with? If so, would the same credentials be shared by every application that is installed? Once you start thinking about this process, you will realize that distribution and management of the credentials is a nasty problem.
Second aspect is around securing these credentials. This secret will be installed with the application. How can we ensure that these credentials would be secured inside the app? What kind of encryption/decryption would be used to keep the credentials. As Ryan Paul pointed out in his post, he could crack the OAuth credentials of the Twitter sample program itself :-(
The issues mentioned above pose less of an issue in server environment. The credentials are secured on the server typically at one place inside the server app. The users typically do not have any access to the installation.
Request Token Authorization Issue:
As part of the OAuth flow, user needs to authorize the access to his/her content. It is achieved by sending verifier code for request token. The OAuth 1.0a specification allows using out-of-band (oob) way where verifier code is handed to the user rather than as a part of browser redirect. However this is not ideal. This is because, the user is then supposed to key in the verifier back in the app. Various ways have been invented to work around this step. However none of them very user friendly. Earlier this year I read around half of the OAuth flows that are initiated on iPhone are never completed.
So, in summary, as I elaborated here any attempt to force OAuth for desktop apps is problematic. Google Buzz and Facebook have both tried to solve this issue in their own way outside OAuth 1.0a specification. Some of this is coming together in OAuth 2.0 draft in the form of different profiles. However it is still something we need to watch and wait for!
Friday, September 17, 2010
Friday, August 6, 2010
NoSQL ... No Kidding
Cloud computing puts a lot of demands over databases. While traditional databases are very good in what they do, they may not be the best fit for cloud computing.
Consider this scenario. Your cloud offering gains popularity and results in hundreds/thousands of new users overnight. You do want to make sure that your cloud offering can support those users and dramatic increase in demand. You might have started with single in house server. Now you must scale well by making use of multiple nodes. Adding new hardware and distributing the load is not trivial process. It also has cost implications. Research in this area suggests that it comes down to fulfilling the 3 important characteristics
* Consistency
This means that each client must always has the same view of the data.
* Availability
This means that all clients must be always read and write.
* Partition tolerance
This means that the system must work well across physical network partitions.
While it is desirable that DBMS should address all the three requirements, it is not possible. The underlying constrains and issues are well captured and described in what is popularly referred to as CAPS theorem.
So, depending on which characteristics are important, more desirable solutions are available. Nathan Hurst has done great job in classifying them.
The solutions are now collectively referred as NoSQL databases (sometimes distributed databases). The NoSQL databses are getting increasing popular to an extent that somebody who is starting out with new cloud offering should think about the value they bring in from the inception. I will try to discuss some of the popular distributed databases in subsequent post.
Consider this scenario. Your cloud offering gains popularity and results in hundreds/thousands of new users overnight. You do want to make sure that your cloud offering can support those users and dramatic increase in demand. You might have started with single in house server. Now you must scale well by making use of multiple nodes. Adding new hardware and distributing the load is not trivial process. It also has cost implications. Research in this area suggests that it comes down to fulfilling the 3 important characteristics
* Consistency
This means that each client must always has the same view of the data.
* Availability
This means that all clients must be always read and write.
* Partition tolerance
This means that the system must work well across physical network partitions.
While it is desirable that DBMS should address all the three requirements, it is not possible. The underlying constrains and issues are well captured and described in what is popularly referred to as CAPS theorem.
So, depending on which characteristics are important, more desirable solutions are available. Nathan Hurst has done great job in classifying them.
The solutions are now collectively referred as NoSQL databases (sometimes distributed databases). The NoSQL databses are getting increasing popular to an extent that somebody who is starting out with new cloud offering should think about the value they bring in from the inception. I will try to discuss some of the popular distributed databases in subsequent post.
Tuesday, July 20, 2010
Deploying at the speed of light
In SaaS environment, it is very important to make sure the service is "always" available. The downtimes in the service impacts wide range of users especially if they are coming from a different timezone. Downtime between 3 AM to 6 AM in US ET may not seem disruptive to anybody in US. However for somebody who is working in Asia or Australia this might eat into major chunk of one's productive hours.
Anyway, the point I am at is in order to keep the service up for the most of the time, it is important to minimize the downtimes. Downtimes are usually needed for emergency patches or software refreshes. That is usually the only way to roll out new features and services. In SaaS environment, it might be daunting task to rollout new upgrade to a number of services. The downtime might then range from few minutes to hours depending on complexity of the environment.
The presentation by Larry Gadea demonstrates some of the challenges that are involved in deploying new builds to servers.
For starters, in case of Twitter,the deployment time was around 40 minutes for a server. With a number of innovative ideas the team was able to reduce it few seconds.
Here is the first general issue. If the farm is to be updated by copying the updates from one central server, usually the central server is the main bottleneck.
One way to solve the issue would be to use tree distribution. However it runs into a problem if one or more nodes in the tree fail resulting in servers that are not updated.
Twitter was able to use an approach that involved using techniques below
The new approach integrated with existing deployment app, Capistrano, resulted in getting the deployment time by about 99%. You can see it here
Anyway, the point I am at is in order to keep the service up for the most of the time, it is important to minimize the downtimes. Downtimes are usually needed for emergency patches or software refreshes. That is usually the only way to roll out new features and services. In SaaS environment, it might be daunting task to rollout new upgrade to a number of services. The downtime might then range from few minutes to hours depending on complexity of the environment.
The presentation by Larry Gadea demonstrates some of the challenges that are involved in deploying new builds to servers.
For starters, in case of Twitter,the deployment time was around 40 minutes for a server. With a number of innovative ideas the team was able to reduce it few seconds.
Here is the first general issue. If the farm is to be updated by copying the updates from one central server, usually the central server is the main bottleneck.
One way to solve the issue would be to use tree distribution. However it runs into a problem if one or more nodes in the tree fail resulting in servers that are not updated.
Twitter was able to use an approach that involved using techniques below
The new approach integrated with existing deployment app, Capistrano, resulted in getting the deployment time by about 99%. You can see it here
Subscribe to:
Posts (Atom)