Valet Key for the Web

Many luxury cars come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will only allow the car to be driven a short distance while blocking access to the trunk and the onboard cell phone. Regardless of the 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.

As the web grows, more and more sites rely on distributed services and cloud computing: 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.

The problem is, 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 – often the same passwords used for online banking and other sites – it also provides these application unlimited access to do as they wish. They can do anything, including changing the passwords and lock users out.

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.).

For example, a web user (resource owner) can grant a printing service (client) access to her private photos stored at a photo sharing service (server), without sharing her username and password with the printing service.  Instead, she authenticates directly with the photo sharing service which issues the printing service delegation-specific credentials.

Beyond Client-Server

In the traditional client-server authentication model, the client uses its credentials to access its resources hosted by the server. OAuth introduces a third role to this model: the resource owner. In the OAuth model, the client (which is not the resource owner, but is acting on its behalf) requests access to resources controlled by the resource owner, but hosted by the server.

In order for the client to access resources, it first has to obtain permission from the resource owner.  This permission is expressed in the form of a token and matching shared-secret.  The purpose of the token is to make it unnecessary for the resource owner to share its credentials with the client.  Unlike the resource owner credentials, tokens can be issued with a restricted scope and limited lifetime, and revoked independently.

On the Beaten Path

Taking inspiration from the Microformats community, the OAuth community made an early decision to base the first version of the protocol on well-established practices. OAuth represents the combined wisdom of many proprietary industry protocols, such as Google AuthSub, Yahoo BBAuth, and Flickr API.

Each protocol provides a different method for exchanging user credentials for a token or ticket. OAuth was created by carefully studying each of these protocols, engaging their authors, and extracting the best practices and commonality to support new implementations as well as a smooth transition for existing services to support OAuth.

An area where OAuth is more evolved than some of the other protocols and services is its direct handling of non-website services. OAuth has built-in support for desktop applications, mobile devices, set-top boxes, and of course websites.

Continue to History

7 thoughts on “Introduction

  1. After reading the introduction of the OAuth model, I am wondering if the model is only relevant for servers opening up an api interface to third party client apps/sites? Our company is looking into REST for clean seperation of server development and frontend development (without the use of JSP’s, but javascript frameworks instead). Both front end and server development will be done by the same IT company (but different divisions and different skills)

    Is it in our case relevant to immediately install such an OAuth authentication model ?

    Any feedback is welcome.

  2. Is Oauth protocol is also good for the implementation of FIM(federated identity management) concepts when compared to SAML. I am considering both performance and security aspects.

    wait a reply,

    • SAML gives you a lot more features and have a more established experience with federated identity. However, OAuth is simpler and will make your developers life easier – you just need to figure out how to make it work for your use case. It doesn’t include FIM support out of the box. One of the main pieces lacking is identifier discovery, but you can accomplish that with LRDD. Then of course there is OpenID.

      • I want to integrate OAuth with my RESTEasy Webservices. Can I use it for Authentication and digesting the password and send it to the service for authentication?
        My only purpose of OAuth here is to allow my customer send the userid/pwd (in digest form and very secure mode) so that the server gives access to it based on the credential validaion.
        Is this something I can do with OAuth for RESTEasy?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s