Wednesday, 29 September 2010

Benefits of using OAuth as your login provider

OAuth has become a popular mechanism to facilitate sharing of data between applications. Another way to take advantage of OAuth is to use it as your login provider. In this post I'll discuss the pros and cons of using it as the login provider for your web application.
To use OAuth for login, all you have to do is to use some OAuth code library and create a consumer application that will connect to an existing OAuth provider such as twitter, linkedIn, Facebook etc. Store the OAuth token in your database, use cookies to save the user login state in the browser and most of the work is done.
The alternative to using OAuth as the login provider can be to implement OpenId or some proprietary login mechanism. Here are some advantages and disadvantages compared to developing or buying a component for login and profile management.

From the end user's point of view:
  • You don't have to create another profile on the net.
  • Fewer passwords to remember.
  • Do not have to submit a password to your application if he / she does not completely trust us.
  • User can prevent access to the application from the OAuth provider.
  • Allows for exciting extra functionality and synergies when taking advantage of the social graph and other data and features made available by the OAuth provider. This may provide much added value.
  • User can not tailor the profile for your application (would require additional development).
  • Can be a bit confusing for the user having to create an account with OAuth providers if he / she does not have an account there already.
From the organization's point of view:
  • Save time on developing authentication, display of user profile and social interaction as friends lists, status updates, profile, photos, etc.
  • Do not need support for password renewal, forgotten password, authentication of users, and support to let users remove themselves from the service, etc.
  • Lower risk and fewer bugs in connection to authentication when using a ready-made proven API.
  • Low-risk for ID theft, etc. The service already has good support to prevent this. Authentication takes place at provider, the OAuth tokens is encrypted and not in our application.
  • If the OAuth standard is extended with support for info cards or other functionality in the future, it might easily be supported in your application.
  • Easier to manage / maintain / configure than forexample extranet login models with mixed authentication (Forms based SAML etc.)
  • Less data to store on your servers.
  • No connections to existing user accounts e.g. in Active Directory if needed.
  • If the remote service is down you have no login (unless the user is already logged in. The authentication cookie is valid).
  • Requires some logic if you will allow the user to log in with multiple OAuth providers.
  • Maybe you (or your company or brand) do not want to associate your self with certain OAuth providers.
  • Maybe the end-user do not want to share his OAuth provider data (LinkedIn / Twitter / Facebook / Yammer, etc) with your application.

More information
Technical description of OAuth
Sample application that shows how login with OAuth in practice