Are all OAuth implementations Created Equal? »

We've implemented a couple dozen OAuth implementations in the past months, and no two have been the same.

We've seen Oauth 1.0a (2-legged,3-legged), Oauth 2.0 (username password, user-agent, web-server flow) with custom token types (bearer,mac, saml).  Just to name a few.

We wanted to write some posts that discuss factors we see that drive these variances and their implications.  We also want to compare and contrast each of these variances along with our own lessons learned. 

First, why the variances?  In our experience, the primary cause of the variance is the type of application that the API is targeted for, which tend to break into one or more of 3 types.

Partner Apps - typically a "closed" API available only to a select group of partners with whom you collaborate very closely to build the apps. For instance - an health insurance provider who is exposing an API that a partner can use to build some health related activity tracing applications.

Open - Browser / Mobile Apps - APIs are exposed to a large community of 3rd party developer from whom you are expecting a large scale of applications to drive innovation. Here you do not control who, how many and what kind of applications get build using the APIs.   For example, mobile applications that integrate with the social networking sites.

Enterprise Apps -  when the API is exposed for use primarily by other enterprise customers - much like a B2B scenario - to allow the customers the freedom and flexibility of building in house Applications and services that mashup one of more of the applications from multiple vendors for internal optimizations.  A good example could be an enterprise that wants to use the Sales Force API along with one other internal apps to build an internal collaboration app.

Depending on the application type above, your approach to an OAuth implementation may vary:

An API for Partner Apps will typically follow a “User name / password” flow.  In this case the end user’s  user name and password will be passed from the user to the partner app and the partner app transmits this to the origin / backend API. The key consideration here is that the partner app will have direct access to the end users credentials and is trusted to treat this information sensibly.

In the Open Browser / Mobile apps scenario the app itself is not inherently trusted and is not allowed to handle the end user credentials directly. The onus of authenticating the end user falls squarely on the origin / backend API provider. The provider (after the end user authentication is successful) will simply issue an access token to the app – this token will correspond to the set of capabilities that the end user has authorized the application for. The sequence of steps followed in this case is commonly referred to as the “user-agent flow” model.

The Enterprise Apps scenario is by far the most robust flow (and understandably, the most complex one too). Here the access token is given to an intermediary server instead of the client device and this facilitates a more secure transmission of the access token. In this scenario, it is possible to restrict the source from which the web service is invoked. This sequence of steps is commonly referred to as the “web server flow” model.

Sounds complicated?  It is. We will try to simplify each of these variants and throw some more light in a series of follow-up entries. Stay tuned!