AT&T's use of OAuth in new API Platform

| | Comments (0) | TrackBacks (0)
Last Monday, AT&T announced that they have launched a new API platform. As I wrote about on Kin Lane's API Evangelist blog, the PaaS includes various components to help developers quickly build and launch new applications. One of these is an HTML5 SDK that simplifies what mobile Web application developers have to do to securely call the mobile network operator's new cloud services.

The carrier is securing their API with OAuth 2. They support both the authorization code and client credentials grant types defined by that spec. att-oauth2.gifThey also allow users to authenticate to the Authorization Server (AS) w/ a username/password, a MSISDN and a PIN, or by simply being connected to their network. Also, each of the services has a different scope. To get approval to use them, the app developer includes these when redirecting the subscriber to AT&T's AS.

The various authentication mechanisms are interesting, but what's even more intriguing to me is a Sencha Touch plug-in that is included w/ the SDK and how it works in tandem w/ a proxy. The plug-in exposes a JavaScript object model for the new cloud services that works naturally w/ this popular toolkit. Extending Sencha Touch like this allows developers who are already using that framework to quickly integrate the carrier's new services. For others that are not, it allows them to build UIs that look and feel like native apps on various mobile platforms while simultaneously simplifying the use of AT&T's API. To see how, let me explain how the Sencha Service Access Layer (SAL) works w/ the proxy.

att-paas-arch.pngAs shown in the following figure, all requests to the AT&T cloud go through an intermediary. This proxy is hosted by the same developer as the HTML5 app. The first time a user invokes the application, it will call the proxy which will find that it doesn't have an OAuth Access Token (AT) or Refresh Token (RT). For this reason, it will return an error rather than calling the carrier's cloud service. The Sencha plug-in will catch this and pop up an IFRAME displaying AT&T's OAuth AS. (The samples don't display the address, but I would.) The user will authenticate as described above, and the AS will redirect the IFRAME to the callback handler which is hosted on the same server as the proxy. It will exchange the Access Code (AC) provided on the query string for an AT and RT. These will be persisted in a session. Subsequently, when methods are called on the plug-in, a request will be made to the proxy, the session will be used to find the AT, and the proxy will tack it onto the request that it forwards to AT&T.

This new API and its SDK provide an innovative way of using OAuth that simplifies the work that mobile Web application must do. The docs were great, the samples were very helpful, and I quickly figured out how to use the toolkit. I also found it interesting that a helper was used here to aid in securely consuming services from mobile apps as I've talked about doing for other use cases.

If you have questions or thoughts about this or the other blog post I wrote about this new API, please feel free to lave a comment here or drop me a note.