Like many people in technical professions, I face the ongoing challenge of explaining my industry to non-technical friends and relatives. Acronyms generally provide the biggest challenges. Explaining that SOAP isn’t a beauty product genuinely took up a significant part of my life in 2001.

Fortunately, people have gotten a lot more tech-savvy in the last decade, partly due to the proliferation and success of well-known tech companies like Apple, Google and Oracle. So when two of those companies get into a huge legal battle over an acronym (in this case, “API”) that’s little known outside technical circles, I welcome attention from mainstream society.

For the last two years, Oracle and Google have been involved in a protracted battle over the APIs for (and resulting implementation of) some Java functionality re-used in the Android mobile operating system. Yesterday marked the first real verdict in the case – in the first of three parts, Google was dealt a minor blow in regards to copying nine lines of code.

Major media outlets have oversimplified the ruling but the real test is yet to come. In a few weeks, the judge will rule on whether APIs are copyrightable. With APIs fast becoming the core means for communicating enterprise data across organizational boundaries, this could have serious implications for enterprise architects.

For example, our partner Eucalyptus Systems implements Amazon Web Services APIs to manage private Cloud infrastructure. A ruling that APIs are copyrightable would have put that usage in jeopardy, if Eucalyptus hadn’t recently announced an agreement with Amazon. Vendors reusing the VMware vCloud API would be in a similar predicament.

Layer 7’s API management products govern interfaces across a variety of message types and transport protocols, so we’re technically agnostic. But we’re intrigued to see APIs being discussed in the mainstream media and we’ll be following the case closely. For more analysis and daily coverage, Groklaw has great recaps. It’s like a geeky version of a TV court procedural.

In recent conversations with our service provider partners and customers, I’ve been hearing a common theme: their enterprise customers are scared of BYOD. The recent trend of employees using their own technology – iPads, smart-phones etc. – to connect with corporate assets worries them. Their main concern is that they won’t be able to keep up with the security and management requirements that go along with this new method of accessing data assets.

While there are existing solutions for playing keep-up, many of them rely on isolation and restriction to prevent corporate assets from traveling too far from the enterprise. Unfortunately, I think employees – especially the more tech-savvy among them – will resent having corporate security policies installed on their devices or being limited to separate-but-equal wireless networks with limited access to the resources necessary to do their jobs. By focusing on containment and control, enterprises are missing an amazing opportunity to make BYOD work for them.

The efficiencies gained by embracing the inevitable and implementing some BYOD-centric systems should not be overlooked. Layer 7 customers are creating mobile applications designed specifically to support their employees, whether their devices are employee-owned or provided by IT.  Our solutions for security and governance of the APIs used by those applications can prevent data leakage, protect against incoming threats and provide access to only appropriate personnel.

So, whether your employees are baggage handlers determining the destination for a piece of lost luggage, nurses providing care to house-bound patients or remote employees connecting to their peers through a corporate directory and communication hub, the real winner is the bottom line. BYOD and mobile workforce enablement are opportunities to embrace – not afflictions to be cured – and we’re here to help.

The ongoing explosion in the amount of online information generated by enterprises has created a need for open, distributed access – a way to get at online content that doesn’t require private user credentials to flow freely over the Internet. The OAuth specification has rapidly emerged as the key standard that enables this kind of delegated access.

At Layer 7, we’ve responded with the creation of our OAuth Toolkit, as well as a series of tutorial videos that explain how enterprises can use the Toolkit to simplify OAuth implementation. Now, in response to the overwhelmingly positive response we’ve received to these tutorials, we’ve decided to give them their own section on our Web site.

This section features all of Francois Lascelles’ popular OAuth 2.0 with Layer 7 Gateways series, with expanded notes and commentary. It also includes one or two of my own tutorials. Over time we’ll be adding demonstrations of how Layer 7 enables connectivity to commonly used OAuth implementations at various social and business networks, including Twitter and LinkedIn.

Last week, I posted a video tutorial demonstrating how Layer 7’s OAuth Toolkit makes it possible to use a SecureSpan or CloudSpan Gateway as an OAuth 1.0/1.0a Server and Client. Today, I’m going to follow that up with a tutorial on how a Layer 7 OAuth implementation can be modified to support custom requirements.

The tutorial demonstrates this thorough the addition of a new parameter, which is extracted from transaction metadata and then used to tweak the implementation. Specifically, I create a policy in which the authorization token’s lifespan is shortened if the user comes in from the browser of a mobile device.

The scenarios I’ve presented in these tutorials represent the two biggest strengths of the OAuth Toolkit – adherence to the specification when you need it and flexibility when you need that.  Our customers have taught us that every OAuth implementation is slightly different and our aim is to give them the tools they need to adapt.

From a technical perspective, rapid adoption of the OAuth standard has resulted in something of a moving target. As the specification evolves, one company may implement OAuth 1.0a, another 2.0, while a third might go with OAuth WRAP. In addition, vague requirements in the spec often result in incompatible implementations, even of the same version.

My colleague Francois Lascelles recently launched a series of tutorial videos demonstrating how Layer 7’s OAuth Toolkit allows enterprises to use OAuth 2.0 to create some really interesting, powerful interaction scenarios.  However, the OAuth 2.0 specification isn’t 100% stable yet, so a real-world implementation must also be able to deal with 1.0a and OAuth WRAP.

For this reason, I’ve come up with a couple of additional tutorials that will demonstrate how our solution can be customized to meet changing requirements. My first tutorial, below, demonstrates a sample application using OAuth 1.0a, which exposes an interface that allows consuming applications to request access tokens and enables users to authorize those apps.

Watch this space for my second video, which will demonstrate how the OAuth Toolkit can be used to customize your implementation.