Here’s an example of how a business partnership might come about these days. Interaction with an online API partner portal will act as the initial “conversation” that leads to the partnership. If you want to integrate with Salesforce.com, you go to the Salesforce partner portal, figure out the relevant SDK/API, build an app and then submit it to the Salesforce AppExchange.  You don’t ever need to actually talk with anyone at Salesforce to become a business partner with the company.

Another example is the way many companies now enable access to their Web sites via Facebook Connect, Google+ Login or Twitter Login. This represents the first step towards establishing a business partnership with Facebook, Google or Twitter. It’s not new in the Web world and has been discussed for years. What makes it relevant to this discussion is the way it’s being applied to out-dated business processes and practices.

Great platform companies have realized this, “robotized” their business development processes and rationalized their business development teams. As robots are to manufacturing, APIs are to business development. Better technology means that we can focus our human resources on more valuable activities, since handshakes are now being made over OAuth instead of costly dinners and drinks.

Smart phones are ubiquitous, social networks are the norm and we are connected to applications on our devices all the time. We love applications like Instagram, Twitter, Evertnote and Snapchat. But we don’t like signing in and out of each of these applications across networks or devices. It’s awkward and cumbersome and we’re often doing it while on the go or commuting, with only one hand to use while tapping in our passwords. Besides, who wants to remember all those passwords anyway? And it’s not safe to use the same one for every application.

This is the major downside of using all these great new mobile applications. Most of us would gladly invite a scenario where we’d only need to log in once to access multiple applications. There’s social login – but is it safe and is our privacy secure? Remember what happened to Burger King’s Twitter account? Enter Single-Sign-On & OAuth for Mobile Applications.

On Tuesday Feb 26, we’ll be hosting a live interactive Tech Talk on security and Single Sign-On (SSO) for mobile applications. And I’m excited to welcome back Layer 7′s Chief Architect and resident OAuth expert Francois Lascelles. He’ll discuss how to provide SSO for mobile applications, without compromising the security of the apps or the APIs that power them. Francois will also be taking your questions throughout the Tech Talk. So, this will be a great opportunity to get answers to your questions about your own applications and the security that surrounds them.

Click here to get the event details and a reminder in your calendar.

On the day of the event, click here to join:

•   layer7.com/live

Submit your questions:

• Tweet using the tag #Layer7Live
• Email techtalk@layer7.com
• Post a message on Facebook

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.

The good old measure of progress, mobile subscriber penetration, doesn’t cut it anymore. Now, the real measure is how many other connected devices a subscriber uses – iPads, Smart TVs and even fridges (who wouldn’t want a Galaxy Kitchen or an iPad Mini?) This is just the start of a revolution in connectivity, which will make it easier than ever to consume information and equally easy to emit a lot of information, often through social networks.

But there is another aspect to this – not only will you be able to post your own information but there will be all kinds of devices that can “sense” information about you. I expect to see a lot of this at MWC – sensors and cameras scattered around the floor, mapping passers-by to Facebook profiles and other personal information. Obviously, the capturing and cross pollination of this information raises all sorts of privacy issues.

It will also have a number of significant ramifications for mobile developers. First, there will be a new wealth of information available in the form of Web service APIs, as most of the data will be stored in cloud. The sheer scale of this new information-rich world will require apps to leverage cloud processing capabilities in order to be truly effective. This will create opportunities for enterprises to rethink their mobile architectures.

Second, mobile developers will need to use standard protocols for authentication and authorization. OAuth and OpenID Connect are key standards for protecting resources and allowing app users to authorize apps to leverage their information. Will these standards address all the privacy issues mentioned above? Probably not but they will make it a good deal easier for app developers to comply with privacy laws and regulations.

Third, the most successful app developers will be those that are able to provide a seamless user experience (UX) across multiple devices. This is because the end user of the near future will naturally expect all apps to know about other sessions that user had with an app across all of his or her many smart devices. Devs will therefore want to migrate sessions across devices, to bolster the UX.

If you’re going to MWC, come and say hello to the Layer 7 team. We will be located in the App Planet area Hall: 8.1 Booth: A47. I hope to see you there!

As you’ll see, all of my predictions are driven by the relentless increase of connected mobile devices. This is the dominating overall trend that will continue to affect all aspects of information systems.

In a nutshell, I predict:

• Individual service deployments on the Web will get smaller and more numerous
• Mobile client deployment will be a bottleneck
• Server mash-ups will increase but client mash-ups will decline
• The demand for seamless switching between personal devices will increase

Services on the Web Get Smaller, More Numerous
Influenced by the existence of the many mobile apps running on a single device, Web-based services will become small, single-focused offerings that (in the words of Doug Mcllroy) “do one thing and do it well.” This will also explode the number of available services. The advantage of this trend will be an increase in the agility and evolvability of service offerings. The challenge will be an increased need for governance at the “micro-service” level.

Mobile Client Deployment Becomes a Bottleneck
As more services appear on the Web and more mobile devices spread throughout the world, keeping up with mobile app deployment will become more difficult and more costly. This is especially true for cases where an app store requires approval before release. To mitigate this problem, developers and architects will look for new ways to update and modify the functionality of already-installed mobile apps without the need for full-on redeployment. Solutions will include use of in-message hypermedia designs, reliance on remote discovery documents and just-in-time plug-in style implementations.

Server-Side Mash-Ups Increase while Client-Side Mash-Ups Decline
The increasing popularity of languages like Node.js, Erlang and Closure will make implementing server-side mash-ups more efficient and easier to maintain than doing the same work within a client application; especially for the mobile platform. This will reduce the “chattiness” of client-side applications and increase the security and flexibility of server-side implementations. The result will be a perceived increase in responsiveness and a reduced use of battery power on mobile apps.

Multiple Device Form Factors Will Demand Seamless Sharing
As more users access content on multiple devices, there will be an increased need to design apps that seamlessly share user data across these devices. This will affect the both client- and server-side implementation details. Identity will need to cross devices easily and content syncing will need to be seamless and automatic. App builders will rely more on the “responsive design” pattern in order to automatically adjust displays and functionality to meet the needs of the current form factor. Servers will need to be “context-aware” and provide the most up-to-date content while users switch from one device to the next.

Finally, whether my predictions are spot on or way off, I look forward to a very interesting and challenging 2013.

Las Vegas Mobile App Hackathon (November 16-17)
The local developer community is thriving in Sin City, which may be a surprise to many. I was very impressed with the talent of the developers in Vegas, most of whom were writing native Objective C or Java for their iOS and Android apps. Also, the local PhoneGap user group manager was onsite, providing support for Adobe’s app development framework. The apps produced were quite polished and impressive. Several included API integrations while others came with plans for future Web integration of APIs, to add context and information.

Miami Mobile App Hackathon (December 14-15)
This hackathon brought an impressive group of sponsors together including AT&T, Microsoft Azure, Blackberry Dev, GitHub and – of course – Layer 7. With over 200 signups and some highly technical evangelists sent by the sponsors, I was excited to see what kinds of apps would be produced. The developers mashed together numerous Web services using native code or PhoneGap. It was great to see the local developer community come together, with numerous local start-up incubator leaders onsite scouting for new talent and investment opportunities.

For 2013, Layer 7 will once again be joining the AT&T Hackathon team for several events. Many organizations with APIs powered by Layer 7 will be promoting their APIs and providing prizes at these events. Stay tuned – we’ll be helping evangelize a lot of great APIs in 2013!

Find out more about upcoming Layer 7 Hackathons

The EULA, however, is important. It’s the foundation of an vital consent ceremony that ends with only one effective choice: pressing OK. This much-maligned step in every software installation is the only real binding between an end user and a provider of software. Out of this agreement emerges a contract between these two parties and it is this contact that serves as a legal framework for interpretation should any issues arise in the relationship.

Therein lies the rub, as the emphasis in a EULA — as in so much of contract law — is on legal formalism at the expense of end-user understanding. These priorities are not necessarily mutually exclusive but as any lawyer will tell you, it’s a lot more work to make them coexist on a more-or-less equal footing.

Mobile devices may provide the forcing function that brings change into this otherwise moribund corner of the software industry. Mobility is hot right now and it is demanding that we rethink a wide span of business processes and technologies. These new demands are going to extend to the traditional EULA and the result could be good for everyone.

Case in point: the New York Times reported recently on a study conducted by the FTC examining privacy in mobile apps for children. The researchers found that parents were not being adequately informed about what private information was being collected and the extent to which it could be shared. Furthermore, many mobile app developers are channeling data into just a few commercial analytics vendors. While this may not sound like too big a deal, it turns out that, in some cases, these data are tagged with unique device identifiers. This means that providers can potentially track behavior across multiple apps, giving them unprecedented visibility into the online habits of our children.

Kid plus privacy equals a lightning rod for controversy but the study is really indicative of a much greater problem in the mobile app industry. Just the previous week, the State of California launched a suit against Delta Airlines alleging the company failed to include a privacy policy in its mobile app, placing it in violation of that state’s 2004 privacy law.

You could argue that there is nothing new about this problem. Desktop applications have the same capacity for collecting information and so pose similar threats to our privacy. The difference is mostly the devil we know. After years of reading about the appalling threats to our privacy on the Internet, we have come to expect these shenanigans and approach the conventional Web guarded and wary. Or we don’t care (see Facebook).

But the phone, well the phone is just… different.  Desktop computers — or even laptops — just aren’t as ever-present as phones. Your phone goes with you everywhere, which makes it both a triumph of technology and a tremendous potential threat to your privacy.

The problem with the phone is that it is the consumer device that isn’t. Apple crossed a chasm with the iPhone, taking the mobile device from constrained (like a blender) to extensible (like a Lego set) without breaking the consumer-orientation of the device. This was a real tour de force — but one with repercussions both good and bad.

The good stuff we live every day — we get to carefully curate our apps to make the phone our own. I can’t imagine traveling without my phone in my pocket. The bad part is we haven’t necessarily recognized the privacy implications of our own actions. Nobody expects to be betrayed by their constant companion but it is this constant companion that poses the greatest threat to our security.

The good news is that the very characteristics that make mobile so popular also promise to bring much needed transparency to the user/app/provider relationship. Consumer-orientation plus small form factor equals a revolution in privacy and security.

Mobile devices tap into a market so vast it dwarfs the one addressed by the humble PC. And this is the market for which consumer protection laws were designed. As we’ve seen in the Delta Airlines case above, the states have a lever and apparently they aren’t afraid to use it.

But legislation is only part of the answer to reconciling the dueling priorities of privacy and consent. The other element working in favour of change is size — and small is definitely better here. The multi-page contract just isn’t going to play well on a four-inch screen. What consumer’s need is a message that is simple, clear and understandable. Fortunately, we can look to the Web for inspiration on how to do this right.

One of the reasons I get excited about the rise of OAuth is because it represents much more than yet another security token (God knows we have enough of those already). OAuth is really about granting consent. It doesn’t try to say anything about the nature of that consent but it does put in the framework to make consent practical.

Coincident with the rise of OAuth on the Web is a movement to make the terms of consent more transparent. This will need to continue as the process moves to the restricted form factor of the mobile phone. I have no doubt that, left to their own devices, most developers would take the easy route and reduce mobile consent to a hyperlink pointing to pages of boilerplate legalese and an OK button. But add in some regulatory expectations of reasonable disclosure and I can see a better future of clear and simple agreements that flourish first on mobile devices but extend to all software.

Here at Layer 7, we are deeply interested in technologies like OAuth and the role these play in a changing the computing landscape. We are also spending lots of time working on mobile because, more than anything, mobile solutions are driving uptake around APIs. When we built our SecureSpan Mobile Access Gateway, we made sure this solution made OAuth simple to deploy and simple to customize. This way, important steps like consent ceremonies can be made clear, unambiguous and — most importantly — compliant with the law.

Recently, we began a series of free eBooks that will distill our communal knowledge into specific, targeted recommendations for dealing with a variety of challenges around APIs – from interface design, to security, to developer engagement. Today, I’m pleased to announce the first two of these, which deal with API exposure for internal mobility projects and for externally-facing open APIs.

First, we have Enterprise on the Go: 5 Essentials for BYOD & Mobile Enablement. This eBook focuses on the challenge of securely exposing internal applications and information assets to mobile employees, either on their own devices (BYOD) or as part of a larger mobility initiative. These five key points for a successful deployment are presented in an easy-to-consume synopsis and then backed up by white papers, webinars and customer case studies. Of particular interest to our enterprise customers are the sections on repurposing existing services and using middleware to optimize for mobile use cases.

Next, we have 5 Ways to Get Top Mobile App Developer Talent for your Open APIs. While not all enterprises have chosen to expose their APIs externally, those that have are faced with the challenge of acquiring a talented community of developers that will build useful mobile apps for the consumer marketplace. However, enterprises can’t simply assume “build it and they will come.” Getting devs onboard requires investment in documentation, branding and community development. This eBook discusses some of the best methods for onboarding and rewarding those developers who provide the most value.

Whether focused on internal or external developers, these eBooks are valuable resources for anyone looking to expose APIs for mobile access to enterprise assets. We welcome your feedback on this format and look forward to continuing the series.

1. Hybrid HTML5/Native Mobile Apps
The term “hybrid mobile app” is often employed to describe an app that is created using a WORA (write once run anywhere) framework like PhoneGap or Appcelerator. These frameworks basically make it simple for developers to generate mobile apps using HTML5, Javascript and CSS.

In the case of Phonegap this app will essentially be a “wrapped” Web site. For PhoneGap apps, developers will often use a UI framework as well, such as JQuery Mobile or Sencha. These UI frameworks look “good enough” on mobile devices, although they should not be confused with the true native UI controls of iOS, Android etc.

In the case of Appcelerator, the generated app can actually leverage the true native sliders, scrollers, date pickers etc. of the device OS. The limitation to this approach is that a developer is fully locked in to what Appcelerator provides. Currently it offers builds for native iOS and Android as well as an HTML5 build, which could potentially be run through PhoneGap.

2. Hybrid API-Driven/Thin-Client Mobile Apps
The term is also used to describe apps that are installed on and run entirely on the mobile device – similar to how a totally native, offline game or other app might work – but which rely on a data connection for presenting Web-based resources, enterprise application functionality or other information assets.

Of course, these information assets are made accessible to the apps via APIs, which is where Layer 7 comes into the equation. In tomorrow’s webinar, I’ll be mainly focused on hybrid mobile apps that are powered by APIs and discussing aspects that are important to address when developing an HTML5 hybrid native app that is also a hybrid API-driven native app. Click here if you want to find out more about the webinar or if you’d like to register.

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.