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.
Ask a question
SearchSecurity.com expert Michael Cobb is standing by to answer your questions about enterprise application security and platform security. Submit your question via email: firstname.lastname@example.org.
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.
Dig Deeper on Web authentication and access control
Related Q&A from Michael Cobb
Geofencing technology is increasingly being used as a security tactic, such as to control access to servers with DNS settings. Expert Michael Cobb ...continue reading
After a remote code execution flaw in PHPMailer was patched, the problem persisted, and had to be repatched. Expert Michael Cobb explains how the ...continue reading
The same-origin security feature in Adobe Flash Player was implemented incorrectly, allowing local attackers to spy on users. Expert Michael Cobb ...continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.