OAuth.io is an API and a service interfacing with more than 80 OAuth providers. This article contains an interview with Mehdi Medjaoui, Co-founder of OAuth.io, providing details on security, licensing and future developments.
OAuth.io is one attempt at simplifying writing code for user or API authorization. Instead of dealing with multiple OAuth providers which might implement different versions of the protocol (1.0, 1.0a, 2.0), a developer can program against a single API as shown in the following snippet:
$('#fb-connect').click(function() {
OAuth.initialize('YOUR_PUBLIC_KEY');
OAuth.popup('facebook', function(err, res) {
if (err) {
// do something with error
alert(JSON.stringify(err));
return;
}
$('#token').html(res.access_token)
.parent().show();
});
});
OAuth.io supports over 80 OAuth providers including Facebook, Twitter, Google (various services), GitHub, Flickr, LinkedIn, Dropbox, etc., and the team behind it is open to suggestions on what other providers to support in the future. The API is accessible as a free or paid service or one could run the service on their own infrastructure.
InfoQ has discussed with Mehdi Medjaoui, Co-founder of OAuth.io, to find out more about this API and its accompanying service.
InfoQ: Is OAuth.io still in beta? If yes, when do you think is it going to become generally available?
MM: The service is already made for production applications. Our biggest production user already integrated 12 OAuth in the same app with OAuth.io.
We have today more than 1380 apps using it, 84 in production, since we launched it 5 weeks ago.
However we have lots of new features which are coming in the next weeks and we still need to validate the service stack on hundreds of thousands or millions of users applications, that’s why we keep the beta phase.
InfoQ: If I understand correctly, a user who wants to authenticate via OAuth.io does that through oauthd, a daemon that runs on Amazon, right? Could you explain a bit the whole process?
MM: OAuth.io is now an API for 80+ OAuth providers. Actually, OAuth.io is a hosted version of oauthd, the open source OAuth daemon we are developing. The OAuth.io service runs on Amazon EC2 and provides an easy and simple web interface for developers to configure and consume their various OAuth providers in a unified way.
What does OAuth.io do?
The user application calls OAuth.popup or OAuth.redirect in JavaScript. It does a request to OAuth.io with the provider to connect to. Then OAuth.io sends the info to popup/redirect to the provider's authorization form. Once authorized, the provider redirects to oauth.io which will request the token and send back to the JavaScript callback in the OAuth.popup / OAuth.callback.
In a server-side flow, the user application just receives a code that is sent (via an Ajax request) to its server. Then the server requests oauth.io with its secret key to exchange the code for the token.
InfoQ: Currently, there is a major security issue: you store the user's private API keys. What do you intend to do about it?
MM: Security is our highest priority in our mission to solve OAuth integration for developers. Security, along with performance and developer friendly experience.
OAuth.io is an OAuth backend-as-a-service for your applications so that’s why we ask APIkeys of applications, like other Backend-as-a-Service (BaaS) do. This is how we manage security with OAuth.io:
- Everything is SSL EV encrypted, to secure the communication between oauth.io and the user.
- The code is single use and with a short expiration time, so no third person will be able to re-use it
- The valid domains/url depend on the detail level: the user can restrict to a single scheme/domain/port/path, so that the redirection cannot be cheated to leak an access token.
- The "state" parameter is now mandatory when doing server-side authorization, to avoid CSRF exploits.
- The client-side/server-side (token/code) is decided in the app configuration, and not in the request, so that getting a token is not as easy as changing a request parameter.
- We do not store any access_token to assure privacy in worst attack cases.
- We have avoided url fragment leaks (getting an access_token from a referrer), because recent Facebook hacks.
- We checked lots of CSRF/XSS potential security exploits and what we have done with Angular.js passed with success all tests
- and globally, the website is API based/driven, so its security is easier to manage.
To be completely transparent for users which want to host their APIkeys, the code is open source and they can install the open source version of the daemon, called oauthd and accessible on Github https://github.com/oauth-io/oauthd
InfoQ: If someone wants to take everything under their control and run oauthd on their own servers, they can license oauthd from you, right? Can you say anything about the licensing conditions?
MM: Yes oauthd is open source under Affero GPL license, the “GPL license for servers technologies”, like MongoDB for example. http://blog.mongodb.org/post/103832439/the-agpl
It is a quite a new license so we need to explain why with AGPL the copyleft does not apply the entire project but only to oauthd modifications.
Because oauthd is a stand alone running application as a daemon, by installing it users have just to redistribute modifications they have made of oauthd under the same open source license to the community, and NOT all the code of the project as other classical GPL license.
That means :
- all open source projects can use oauthd for their apps and projects.
- closed source projects using oauthd as a stand-alone server needs to redistribute only modifications of oauthd back to the community (and NOT the whole project)
We provide a commercial license for companies that are interested to have oauthd into their server to keep closed the modifications they have made on oauthd or the code they linked to oauthd. The price of the commercial license depends on the support service required.
To understand more about AGPL :
Our goal with using AGPL is to preserve the concept of copyleft with oauthd. With traditional GPL, copyleft was associated with the concept of distribution of software. The problem is that nowadays, the distribution of software is rare: things tend to run in the cloud. AGPL fixes this “loophole” in GPL by saying that if you use the software over a network, you are bound by the copyleft. Other than that, the license is virtually the same as GPL v3.
InfoQ: What is on the roadmap? Do you plan to add support for more languages, other than JavaScript?
MM: Yes indeed. Our next step is going on mobile with iOS, Android and BlackBerry SDKs. We have received hundreds of emails asking to go on mobile first, before other languages. We expect launching all these SDKs on early September.
Then we will make the other Python, Ruby, PHP, .NET and Java SDKs by the end of the year.
