If you reached this blog and you are not a Mule user (yet) keep reading, I will not cover anything Mule specific. If you are new to OAuth or want to get an introduction to its concepts this post is the right one!
Authentication is vital in any kind of system but it is even more relevant when it comes to the web. As the web grows, more and more sites rely on distributed services and cloud computing. As resources are spread all over the web, sharing them across multiple sites is not an unrealistic requirement considering the following scenarios: a photo lab printing your Flickr photos, a social network using your Google address book to look for friends, or a third-party application utilizing APIs from multiple services. In order for these applications to access user data on other sites, they ask for usernames and passwords. Not only does this require exposing user passwords to someone else it also provides these applications unlimited access to do as they wish.
The valet key metaphor
I will borrow this metaphor from Eran Hammer-Lahav and use it as starting point to go over OAuth:
“Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using another key to unlock everything else.”
How is this related to authentication and OAuth? The regular key would be your user name and password, whoever has them will access your resources without any limit (just as if it were you). So the question is what you can do when you just want to give someone limited access to your resources but without disclosing your credentials and at the same time being able to revoke the access at any time. Keeping this things in mind we can resume what we want from an authentication method:
- give partial/restricted access to the protected resources;
- avoid disclosing your credentials to a third party site;
- revoke access to these resources at any time.
OAuth
The solution to this problem is OAuth. OAuth provides a method for users to grant third-party access to their resources without sharing their passwords. It also provides a way to grant limited access (in scope, duration, etc.). I will leave the details of OAuth 1.0 and OAuth 2.0 to a later post and focus on the basics for now. Associate the following concepts with the valet key metaphor. Stay with me!
- Service Provider: a web application that allows access via OAuth.
- Resource Owner/User: an individual who has an account with the Service Provider.
- Consumer: a website or application that uses OAuth to access the Service Provider on behalf of the User.
- Protected Resource: data controlled by the Service Provider, which the Consumer can access through authentication.
Have you figured out how these terms map with the valet key metaphor? The Protected Resource is the luxury car. The Resource Owner is the owner of the car. The consumer is the parking attendant. The Service Provider well… it is not very clear… the Resource Owner is also the Service Provider because it not only owns the resources but has the means to provide access to them.
The Resource Owner instead of giving the credentials to the Consumer, authenticates against the Service Provider and Service Provider passes a Token to the Consumer with which it can access the Protected Resources. This Token provides limited access to the resources, for example it will not be possible for the Consumer to change the Resource Owner’s password as it can happen when passing the user name and password! Additionally, the Resource Owner can revoke access at any time, invalidating the Token the Consumer has.
Conclusion
I have not yet dealt with the complexities of OAuth (version 1.0 in particular) but as you can see this mechanism allows sharing resources across multiple sites in a safe way. Also, the user who owns these resources is in control of the situation as he/she can revoke access to third part sites at any time. In most sites you have an “Application” menu in your personal settings where it lists all of the sites you allowed access and gives you the option to cancel their access. The terminology can be confusing so just make sure you remember the valet key story and the concepts will clearly emerge.
In my next post I will go over OAuth 1.0 flow and then finally I will show how Mule can help you easily build integrations around APIs that use OAuth. Stay tuned!
Follow: @mulejockey @federecio
