I’ve seen a number of posts stating that Open Authorization (OAuth) is not a good/safe/efficient protocol for Single Sign-on (SSO). The main argument is that OAuth is intended for authorization (asking permission to use a resource) rather than authentication (confirming a user is who they say they are). The reality is that before you can grant a user permission to a resource, you need to be sure that the user is who they say they are. So, OAuth really does both. If I create a “permission” called “may use my entire application” and use OAuth to grant that permission, then OAuth becomes an authentication system.
The main issue is that OAuth is geared toward one application accessing another application as opposed to a user on a browser accessing an application. OAuth has a number of handshake mechanisms but they all have the goal of providing one application with an “access token” which is a special code that it can use to access information from another application. This code is not intended to be ever given to directly to the user (or the user’s browser). This is why OAuth is very popular for mobile applications. Typically, the user accesses an application on the web from another “app” on their phone or tablet. For example, if you have access Facebook from your phone, you usually don’t use a phone browser, but use a Facebook app which in turn talks to a Facebook server out on the web. The Facebook server is willing to give all your info to your phone’s app because your app send an OAuth token to the server. What’s nicer is that you don’t need to give your Facebook app your Facebook password to make this work.
Often both technologies need to be combined. If you have a mobile application but want you want to log-on only once with your corporate user name and password, then you very likely want to use SAML for the corporate sign-on and OAuth for the mobile App. This scenario will be the subject of our next OAuth blog.