OAuth 2.0: Pros and cons of using the federation protocol

Our organization is strongly leaning toward integrating OAuth into our Web application authentication architecture in order to support both standard and mobile Web apps. Are there any downsides to using OAuth, particularly with mobile applications, or any reasons why we should consider other methods or federation protocols?

OAuth 2.0 (Open Authorization) is currently nearing finalization as an IETF standard. It is a federation protocol aimed at simplifying authorization and access to protected data by giving access to data while protecting the owner’s account credentials. It allows a user with an account on one website (the service provider) to allow another website (the consumer) to access his or her data from the first website. Users can give out tokens instead of credentials -- typically their username and password -- to share access to their private resources such as documents, images and calendars hosted on the Internet. A token can grant access to a specific resource for a specific duration so resources can be shared with a third party without having to grant complete access to all the data. This is a far better solution than users sharing their usernames and passwords with each other in order to access each other’s data.

One of the potential benefits of OAuth 2.0 is the ability for users to share verifiable assertions about themselves without having to release any personally identifiable information.  Allowing your customers to either aggregate your information about them or share information about themselves from another site with your application could greatly improve your services, tying together functionality from other sites while reducing costs at the same time.

OAuth is used by many large sites, including Twitter, Facebook and Google. Choosing an alternative protocol would be difficult given this level of support from the biggest sites on the Net, but OAuth is not a simple plug-and-play technology. When using the OAuth protocol, you need a secret string obtained from the service you want to delegate to. From reading various blogs and forums, I gather that developers struggle with managing this secret on mobile devices, as storing it in the application means it could be found and misused.

Also remember that OAuth is about giving access to resources without sharing the owner’s identity or credentials; i.e., a temporary data transfer authorization. Users still have to sign in at some point with a username or password, even if they’re using OpenID and using a single identity to sign into many sites. I would conduct some usability tests on your proposed design to see how your users react. Some may prefer to enter a username and password rather than click to login to Twitter, enter their username/password there, click submit, click approve and finally return to your site.

We are still some way off from a standardized authentication and authorization framework for mobile applications, but companies for whom it’s a key aspect of their business model, such as Google, are working on it. Until then, OAuth 2.0 is probably your best bet as long as you bear in mind your users’ requirements as well as your own.