Authorize Social App Access with OAuth

If you ever accessed a Facebook application that asked you to review a list of permissions that the application is requesting and then click OK, you have seen OAuth in action. You can use OAuth on your business' social collaboration tools in the same way.

OAuth outlines a method for giving one application access to another, with the user’s permission. In particular, the user is giving access to something private, such as an e-mail address, affinities reflected in a social profile (things Liked, groups joined), or a collection of photos.

Say you want to provide a printing company access to your photos on Facebook or another photo-sharing site to print a custom calendar with your kid’s pictures.

The process goes like this:

  1. Authorization is requested.

    The client application requests access to a protected resource. In the example above, the client application is the printing service, and the protected resource is the photos on Facebook.

  2. The authorization grant is returned to the client for approval.

    The user (you) grants access. This process is mediated by the social networking platform, which you presumably trust, in the form of a user interface that makes clear what rights you are granting. If you say no, the process stops.

  3. The authorization grant is relayed to the authorization server.

    The client application presents the authorization grant as proof that it should be provided with an access token, which is a key that it will be able to use to access the protected resource.

  4. The access token is returned to the client.

    The social networking server in charge of protecting your identity verifies that the digital credential presented as proof of authorization is legitimate and then returns an access token.

  5. The access token is sent to the resource server.

    The server in charge of the protected resource (your photos) receives an access token (the key) along with a specific access request.

  6. The resource is returned to the client application.

    First, the resource server validates the access key. If it checks out, the print shop app gets access to your photos.

After going through the process once, the client application can continue to use the key you have given it to unlock the server containing your protected resource. By granting access, you’re saying that you trust this application to act on your behalf and not against your interests.

Here’s another simple example: If you give an online magazine access to your social profile so it can show you more of the articles that you tend to like, it will be able to continue to access the most current version of your profile on subsequent visits.

Access tokens can be set to expire and can be revoked, however. When you remove an application from your profile, you’re telling the social platform that access token should no longer be honored.

Much debate remains as to whether OAuth strikes the right balance between security and ease of use. When representatives of enterprise IT organizations and their vendors got involved in defining OAuth 2.0, some web purists complained that the specification was becoming unnecessarily complex. On the other hand, OAuth 2.0 was designed to be easier to implement than the previous version, and some security advocates worried it may become too easy to hack in the process.

OAuth may not be perfect, but it has been widely adopted as a way of sharing profile data and other protected resources between applications.

  • Add a Comment
  • Print
  • Share
blog comments powered by Disqus
Advertisement

Inside Dummies.com