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.

What about the classic scenario where there are two apps on the web and the user has a plain-old browser? Since the two apps never talk to each other directly, a mechanism would need to be devices where the user logs onto App A, receives and access token into their browser and passes it through to App B with then calls back to App A via some API to make sure the access token is valid. It could be done but both the mechanisms of passing the token via the browser and calling back to validate the token would be proprietary. Further, we’ve passed the access token into the user’s browser so it’s possible it could be snatched (perhaps by some malicious javascript). This is why most developers stick to the standard SSO protocols like SAML, OpenID and WS-Federation for the classic web-app to web-app single sign-on.

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.

Learn More