INTRODUCTION TO OAUTH

OAuth is an open standard managed by the Internet Engineering Task Force and is designed to allow applications to access services in a Web-friendly manner on behalf of an application or user.

Some might ask, “Why not just give the caller my username and password?” This unfortunately poses some issues that OAuth avoids:

• The app can do everything and anything your account can do. This means that if the calling code had your username and password it could, for example, change your password or do things that you would rather it didn’t have access to. Because the app has your username and password it is as if you are making the calls and the service has no idea who the real caller is.
• To the service, all calls look the same whether it is you or the calling app making the calls. This means keeping an audit trail is almost pointless because there is no way to tell who the caller really was if the same username is being used each time. Additionally, if you give your username and password to multiple services and one of them deletes information, you have no way to know which one it was. Obviously, this could cause some problems if you are not careful.
• You can’t revoke access to a particular service without changing your password. This means that you would need to update your password on all those services that you want to continue working. If a few services are involved this task can be error-prone and cumbersome.

Here is a simple analogy to help explain this concept. Imagine an office building that is secured using swipe cards. A lot of sensitive information is stored in this office building and many people work in it each day. Now imagine each of those workers were issued the exact same swipe card. From the door lock–system logs you couldn’t tell who was accessing the building and when. Additionally, if you fired a worker and she didn’t give her swipe card back you would need to reissue everyone one else a new key. This is the same as sharing your username and password.

To solve these issues, OAuth introduces the concept of an application identity or application principle. This is simply an identity given to an app much the same way a user has a username and password. It offers the ability to control and manage access to resources at an application level versus a user level, and therefore you don’t need to give an app your username and password to access any desired resources. Furthermore, this means an app’s access can be monitored, audited, and revoked if needed. For an app to gain access to a service the user must deliberately grant that specific application access to that specific service. Access is only granted once that app identity is checked and verified as valid with permissions to the resource. This access may be scoped to specific resources within the service. This means, for example, that the user could grant the app access to some data, but not to change the user’s password. This also means that a user may revoke an app’s access to the service at any time without needing to affect other applications’ access.

So, revisiting the analogy, if the building security system used an OAuth style access system, each worker in the building would be granted an ID, and then his swipe card with that ID on it would be granted access to the particular areas of the building that he was allowed to be in. When a worker is revoked access, the building owner simply revokes access for that worker’s ID in the system. That way when the worker tries to swipe in he is denied access. Or, in the case when a worker changes departments, the building owner simply signifies that for that particular ID the person is now denied access to Level 1, for example, and is allowed access to Level 2. It’s the same in OAuth. Each app (the equivalent of a person in the analogy) is granted an ID and a set of privileges. When the caller tries to access a resource, the ID is verified and a check is made to ensure he is allowed access to that particular resource. If access is allowed, the call proceeds and if not, the caller is denied.

OAuth is supported and used by many large services on the Internet today such as Facebook and Twitter. Numerous open source libraries exist for various languages to assist with the standard OAuth messages involved in authorizing and calling a service. The SharePoint 2013 app framework and tools also include many helper libraries and functions to wrap a lot of the underlying OAuth protocol exchanges. In many cases a developer might never be aware of the communication and messages OAuth uses behind the scenes.