I speak about the power and flexibility of hypermedia quite often. I explain the general idea behind hypermedia, discuss its historical roots and show how it can help client applications adapt to changes in data input and application flow. Essentially, a hypermedia-based approach aims to take key elements often placed into the client’s source code and move them into the actual response messages sent by the server.

I also point out that using a hypermedia-based approach to building client and server applications takes a different kind of effort than using RPC-style approaches. And I explain that, currently, there is a limited amount of tooling available to support the process of designing, implementing and maintaining hypermedia-style systems.

If your work involves designing, building, testing and deploying a mobile client application, it is likely you need to deal with an “application store” or some other process where your packaged application must be submitted for review and approval before it is available to users for download. This can happen not only with well-known public offerings such as the Apple Store but also within any organization that provides its own application repository aimed at ensuring the safety and consistency of user-available mobile apps.

In an environment of quick-turnaround, agile-style implementations this “app store” approval can be a real bottleneck. It may be not just days but weeks before your app is tested, approved and posted. This can be especially frustrating when you want to deploy a rapid-fire series of enhancements in response to an engaged user community.

A hypermedia-based client design can often support UI, data transfer and workflow modifications by altering the server messages rather than altering the client source code. By doing this, it is possible to improve both the user experience and the system functionality without the need for re-submitting the client code for “app store” review and re-deployment. This also has the potential to reduce the need for interrupting a user’s day with download and reinstall events and can, in the process, cut down on the bandwidth costs incurred during the repeated roll outs of code modifications to a potentially large user base.

Improved agility, a better user experience and reduced bandwidth costs are all tangible benefits that are possible when investing in a hypermedia-based implementation for your mobile client application.

APIs are the foundation of modern business. Everything we do, from buying a coffee to checking the weather or booking a flight, is supported by a robust API architecture in the background. Businesses likewise assume that they can exchange information and build compelling new services based on APIs.

This is causing disruption across industry sectors but also opportunity and it is having a particularly marked impact on the telecommunications industry. With the proliferation of next-generation communication services, consumers and enterprises alike are looking beyond their network service providers and finding exciting new ways to consume content, engage with businesses and communicate with friends or colleagues.

Telcos haven’t been ignoring this by any means, yet several iterations of failed API strategy have led not only to lost revenue opportunities but – in many cases – huge expense as well. However, now is not the time to cast aside these investments or ignore the exploding API economy – and in fact, we’ve heard plenty of success stories from companies that took the correct approach. Telcos must participate and open up more and more services to keep pace with this economy. And they must do so without compromising data and network security.

Layer 7’s new white paper, APIs & the Business of Telecoms, written by independent telecommunications thought leader Alan Quayle, aims to help telcos understand how they can quickly address the functional and non-functional requirements of a successful API exposure program. This is essential reading for all telcos – APIs really are the future!

A recent study by researchers at North Carolina State University and the University of Oregon describes a threat scenario that allows attackers to exploit cloud-based resources for malicious purposes like cracking passwords or launching denial-of-service attacks. The study has gotten a lot of attention, including articles in reputable sources like Dark Reading, Ars Technica and Network World.

In order to optimize the performance of mobile apps or browsers, some computation-heavy functions have been offloaded to cloud-based resources, which in turn access backend resources and Web pages. This creates a middle ground in the cloud that is exploited in the attack, which the authors call “Browser Map Reduce (BMR)”. In reading the paper, it’s clear that this is a legitimate threat. The authors actually carried it out using free resources, although they limited the scope in order not to be abusive.

Aside from questions of curiosity around the mechanics of the vulnerability, the obvious question is this: How can we mitigate this threat? Here are a few perspectives here as well as a method for each.

Apps – This “cloud offload” architecture has arisen because of the processing limitations of mobile devices. When a backend resource is requested by a mobile user, it makes sense to have the data returned in the most consumable format, in order to optimize user experience. Whenever possible, instead of doing this through “browser offload”, data should be returned as JSON objects. This API approach is a proven method that works for mobile devices and is not subject to the BMR threat.

Cloud Services – This threat should not be viewed as a dismissal of the “cloud offload” approach. Cloud-based resources are necessary for handling caching, data indexing and other key functions in the mobile paradigm. However, it serves as a warning that these dedicated cloud-based resources cannot be considered part of a walled garden that includes the associated mobile app. The resource’s entry point must be protected against attackers. Layer 7’s SecureSpan Mobile Access Gateway is an ideal choice for this access control, as it uses identity-based measures to ensure that only requests from legitimate sources are serviced.

Web-Based Resources – Although the backend Web resource was not exploited in this scenario, the study is a reminder that the topology of the mobile Web is changing and increasing in complexity. P2P app-to-API connections cannot be assumed and therefore inbound API calls cannot be implicitly trusted. API access must be controlled and the SecureSpan API Proxy is a leading solution for this purpose.

To sum up, this is a legitimate threat but not a reason to abandon the use of cloud-based resources for mobile app optimization. Be aware of the threats, employ the mitigations and then you can continue to enjoy the exciting growth of the mobile Web.

I’m excited to welcome back our API Evangelist Alex Gaber to do his second Tech Talk. Back by popular demand, Alex will take your questions on Optimizing Cloud-Driven Mobile Apps. Alex is a dynamic speaker who knows the app economy inside and out, has built several of his own mobile apps and regularly host hackathons all over the globe.

Building cloud- and API-driven mobile apps introduces complex challenges around syncing, caching and securing data. So, connect live with Layer 7 on Tuesday November 20, at 9am Pacific Time, when Alex will be answering your questions about how to address these challenges. Alex will also provide insight into a range of related best practices, including techniques for building cross-platform applications in HTML 5.

Click here to get the full event details and a reminder in your calendar. On the day of the event, join the event at layer7.com/live and tweet questions to #layer7live.

Here’s an interesting pattern that we’re constantly running into at various API Management projects: runtime mapping between a token used by external mobile applications and another form of authentication required by an internal system. The need for this comes up when a legacy API/service with an existing access control mechanism needs to be exposed to a mobile application for which the current access control mechanism is not appropriate.

Example 1: Kerberos-Constrained Delegation
Services and APIs developed using Microsoft stacks often expect a Windows identity at runtime for role-based authorization. Providing a Kerberos ticket all the way to a mobile device outside the security domain is an anti-pattern. Instead, the user of the mobile application is subjected to an OAuth handshake. The authorization server leverages the user credentials at handshake time to also get a Kerberos ticket on behalf of this user and stores it as part of the OAuth session – see the token lifecycle management concept explained in this previous post. The OAuth access token is mapped to the Kerberos ticket at runtime when the API calls are made by the mobile application.

Example 2: An SSO Token
Many backend services were originally intended to be consumed by Web applications. When the user of a Web application logs into the Web portal, a session is created in the IAM solution and when the Web portal needs to consume the internal API on behalf of the user, it leverages this same SSO token. I’m thinking here of solutions such as CA SiteMinder, Oracle Access Manager etc. When this same API is now consumed by a native mobile application, instead of a Web application, the existing login flow is no longer adequate. Again, an OAuth authorization server is leveraged to create a session between the mobile application and the API Management infrastructure. In this case, the OAuth authorization server will get the SSO token created at the same time as the front-side access token and map between the two at runtime.

This pattern is applicable no matter what the internal token is. Other common forms for these internal tokens include a SAML assertion issued by an STS and session IDs issued by the backend service itself through a /login method. Note that baking such login methods directly into an API constitutes an anti-pattern but the token mapping offers a non-intrusive “resolution”, which restores proper decoupling at the perimeter whilst avoiding any change to the legacy backend.

OAuth Handshake
During an initial OAuth handshake, the OAuth authorization server is provided with credentials for the user. These credentials might be provided by the application itself in the case of a resource-owner-password-credentials grant type or by the user via a login form directly on the OAuth authorization server. The best practice is to use password grants for trusted applications (applications provided by the same provider of the API itself) and to use the implicit or authorization-code grant type for third-party applications. These credentials are used by the OAuth authorization server to authenticate the user and issue an access token. In addition to this, the OAuth authorization server may use the user credentials during this same process, to get an internal token issued by doing its own handshake with the internal token server/STS or by making a /login–style API call. The OAuth access token is returned to the mobile application and both tokens are stored as part of the OAuth session, alongside the other properties of the session, such as scope, timestamps etc. Note that there is often a temptation to store the user credentials as part of this session for later use but this is not recommended.

It makes sense to align the life spans of both the internal and external tokens so that they can be reissued together when they expire. Whenever these tokens need to be reissued, the OAuth authorization server will again be the component driving this. For better user experience, the mobile application will often want to avoid prompting the user for credentials. The OAuth standard accommodates this through the concept of refresh tokens but the internal token issuing pattern doesn’t always do that. For example, Kerberos-constrained delegation will let you get a new Kerberos token without the user’s password but other systems will not allow for that. This is often the source of motivation for storing the user credentials as part of the user session as mentioned above. You can instead allow for an internal token with a longer lifespan than the external token and reuse the existing internal token at OAuth refresh time.

Runtime Mapping
At runtime, the mobile application consumes an API on behalf of the user by calling the OAuth resource server, the runtime analog of the OAuth authorization server.

The OAuth resource server is the component responsible for validating an incoming OAuth access token. At runtime, the resource server can retrieve session information associated with the token presented by the application from the token management layer. The resource server will look at the scope and determine whether or not the API call should be authorized or not. When access control is completely assigned to the API Management infrastructure, the resource server makes all the authorization decisions, then passes the API call to the backend API endpoint but in this case, the backend API has its own authorization mechanism. To accommodate this mapping requirement, the resource server retrieves the internal token associated with the access token presented by the mobile application and injects it to the API call to the backend service.