The recent Mobile World Congress event in Barcelona reminded us about the growing importance of APIs to the telecommunications sector. Telco was actually one of the first sectors to show an interest in APIs but most carriers have still not taken full advantage of the opportunities presented by APIs and some have got their fingers burned trying to court the long tail of third-party app developers.

Still, with Web and mobile technologies creating competition from outside the telco sector, carriers need ways to quickly adapt to technological change – and APIs provide the perfect solution. APIs allow telcos to open up their services for efficient repurposing by internal developers and partner organizations, creating opportunities for being quick to market with innovative new offerings.

Layer 7’s latest eBook 5 Ways Every Telco Can Benefit from APIs provides an overview of how carriers can realize these opportunities. If you visited the Layer 7 booth at MWC, you might have picked up the print version of this handsome document. If not, don’t hesitate to download the electronic version.

John Chambers, CEO of Cisco, just published a good blog entry about the potential for change caused by universal connectivity – not just of our mobile gadgets but of pretty much everything. Recently, much has been said about the so-called “Internet of Things” (IoT), of which Cisco is expanding the scope, going so far as to make a bold estimate that 99.4% of objects still remain unconnected. This, of course, is great fodder for late-night talk show hosts. I’ll leave this softball to them and focus instead on some of the more interesting points in Chambers’ post and the accompanying white paper.

It strikes me that there might be more to Cisco’s “Internet of Everything” (IoE) neologism than just a vendor’s attempt to brand what still may be a technology maverick. Internet of Everything sounds so much better than the common alternative when you append “Economy” to the end – and this is how it first appears in Chambers’ post. And that’s actually important because adding economy in the same breath is an acknowledgement that this isn’t just marketing opportunism as much as a recognition that, like mobility, the IoE could potentially be a great catalyst for independent innovation. In fact, Cisco’s white paper really isn’t about technology at all but is instead an analysis of the market potential represented in each emerging sector, from smart factories to college education.

It is exactly this potential for innovation – a new economy – that is exciting. The combination of Mobile Access and APIs was so explosive precisely because it combined a technology with enormous creative potential (APIs) with a irresistible business impetus (access to information outside the enterprise network). The geeks love enabling tools and APIs are nothing if not enabling; mobile just gives them something to build.

I0E, of course, is the ultimate business driver and –  with APIs as the enabler – it equals opportunity of staggering proportions. Like mobile before it – and indeed, social Web integration before that – IoE will come about precisely because the foundation of APIs already exists.

It is here where I disagree with some IoT pundits who advocate specialized protocols for optimizing performance. No thank you; it isn’t 1990 and opaque binary protocols no longer work for us, except when streaming large data sets (I’m looking at you, video).

Security in the IoE will be a huge issue and Cisco has this to say on the topic :

“IoE security will be addressed through network-powered technology: devices connecting to the network will take advantage of the inherent security that the network provides (rather than trying to ensure security at the device level).”

I agree with this because security coding is still just too hard and too easy to implement wrongly. One of the key lessons of mobile development is that we need to make it easy for developers to automatically enable secure communications. Take security out of the hands of developers, put it in the hands of dedicated security professionals and trust me, the developers will thank you.

As IoE extends to increasingly resource-constrained devices, the simpler we can make secure development, the better. Let application developers focus on creating great apps and a new economy will follow.

Are you a token distributor? If you provide an API, you probably are.

One thing I like about tokens is that, when they are compromised, your credentials are unaffected. Unfortunately, it doesn’t work so well the other way around. When your password is compromised, you should assume the attacker could also get access tokens to act on your behalf.

In his post The Dilemma of the OAuth Token Collector and in this twitter conversation, Nishant Kaushik and friends comment on the recent Twitter hack and discuss the pros and cons of instantly revoking all access tokens when a password is compromised.

I hear the word of caution around automatically revoking all tokens at the first sign of a credential being compromised but in a mobile world where user experience (UX) is sacred and where each tapping of a password can be a painful process, partial token revocation shouldn’t be automatically ruled out.

Although, as Nishant suggests, “it is usually hard to pinpoint the exact time at which an account got compromised”, you may know that it happened within a range and use the worst case scenario. I’m not saying that was necessarily the right thing to do in reaction to Twitter’s latest incident but only revoking tokens that were issued after the earliest time the hack could have taken place is a valid approach that needs to be considered. The possibility of doing this allows the API provider to mitigate the UX impact and helps avoid service interruptions (yes, I know UX would be best served by preventing credentials being compromised in the first place).

Of course, acting at that level requires token governance. The ability to revoke tokens is essential to the API proviver. Any token management solution being developed today should pay great attention to it. Providing a GUI to enable token revocation is a start but a token management solution should expose an API through which tokens can be revoked too. This lets existing portals and ops tooling programmatically act on token revocation. Tokens need to be easily revoked per user, per application, per creation date, per scope etc. and per combination of any of these.

Are you a token distributor? You should think hard about token governance. You also think hard about scaling, security, integration to exiting identity assets and interop, among other things. We cover these issues and more in our new eBook : 5 OAuth Essentials for API Access Control.

Today’s lead article on Ars Technica talks about the importance of protecting backend resources in the context of mobile applications. The article rightly stresses the importance of this security, talks about the uptake in OAuth and cites API Gateway solutions as a popular option in this space.

However, the article clearly misstates the capabilities of an API Management solution founded on an API Gateway. I am going to assume that the author only had exposure to API Gateways second hand or through a competitor of Layer 7. Here are the misconceptions propagated by the article, along with some corrections:

“These API gateway services can be prohibitively expensive for small-scale applications…  ‘You can replicate the API gateway by creating a set of proxy services in their data center in an application container in their DMZ.’”

Trying to create your own homegrown set of proxy services is expensive and risky. The Layer 7 API Management Suite’s Gateway technology includes 10 years of functional enrichment and optimization. Such robustness cannot be hacked together on the fly.

“An API gateway still runs on the notion that you have to be careful not to block what might be legitimate traffic. So that could cause some openness – some attacks might slip through using Web application firewall evasion techniques.”

An API Gateway is not a typical web application firewall. Layer 7’s Gateway (evident in the company’s name) has full access to all layers of the data stream and can apply protections at any of these layers.

“Of course, if they can retrieve a developer key, attackers can slip past API gateways until their activity is noticed…  That’s why it’s important to encrypt any data stored on the device, including developer keys[.]”

API keys are not treated as security tokens by an API Gateway. The term “API key” is equivalent to a “database key”, not a security key, so don’t mistake it for a robust access control mechanism. It is mainly an identification mechanism. It is a gross misunderstanding to equate API developer keys with a standard access control cryptographic mechanism like PKI public/private keys.

“But keys have other ways of getting into the wild besides breaking into the application code.”

Right, so you should not rely on these keys for access control. The good news is that the API Management Suite’s Portal/Gateway combination makes it easier to revoke and reissue developer keys.

“For enterprise applications, an API gateway isn’t always enough – users need to get access to content on servers inside the firewall that may not be easily exposed through a Web API.”

And this is where the API Gateway really adds value. The Layer 7 API Management Suite allows companies to turn those backend interfaces from their native protocols into REST APIs or other formats that are friendly to mobile devices.

So, thanks to Ars Technica for flagging up this important aspect of mobile security and here’s hoping that this corrected information is included in the next article.

Earlier this week, Forrester Research, Inc. released The Forrester Wave: API Management Platforms, Q1 2013. This report addresses products targeted at several different audiences including API business owners, technical administrators and application developers consuming APIs. We’re proud to announce that the Layer 7 API Management Suite has been recognized as a Leader in the category, with some significant distance between ourselves and our peers.

What I’m most proud of is our consistently high marks in every category; we have worked hard to make sure that our products provide both ease-of-use and deep functionality. The developer experience is just as important to us as the rich integration capabilities provided to technical architects and API administrators. And comprehensive business analytics for API owners are just as important as the availability and security features required by enterprise operations teams. Our scores reflect this breadth of solution strengths.

What might be more difficult to reflect in an “Emerging Market” Wave is product depth – and this is another area where Layer 7 shines. Enterprise customers value our flexibility in deployment options, our support for numerous message formats/protocols, our rich identity framework and our long list of security certifications gained through exhaustive testing and evaluation by some of the most demanding organizations and standards bodies in the industry. Our customers have long recognized Layer 7 as a Leader in this category and we thank Forrester for validating this with the first major analyst evaluation of API Management vendors.

Layer 7 had a similar previous showing in The Forrester Wave: SOA Application Gateways, Q4 2011, in which the company was also recognized as a Leader. This successful heritage is noted by Forrester in the new Wave, which states that “Technical adopters will find a lot of depth to Layer 7’s service management capabilities, including a variety of deployment options, sophisticated traffic shaping and routing capabilities, and extensive connectivity to existing enterprise systems.” By bringing these strengths to bear on the API Management industry, Layer 7 offers an IT-friendly option for enabling all open enterprise API use cases, including access to partners, developers, mobile apps and cloud platforms.

Get a complimentary copy of The Forrester Wave: API Management Platforms, Q1 2013