Two weeks ago the Wall Street Journal ran the story ‘Sam's Club to Use Wi-Fi to Push TVs,’ highlighting internet-connected TVs which run popular social media or video applications. Last week WSJ highlighted how cable companies are getting their content on the iPad in response to excellent execution by Netflix and Hulu. This week, WSJ reports how businesses like law firm Sonnenschein Nath & Rosenthal, Bausch & Lomb, and Mercedes-Benz Financial are adopting the iPad as a business tool. APIs are all over the business press as early leaders emerge and competitive pressure to succeed in the multi-device web heats up.
Chris Anderson sees the trend. From his excellent feature article in this month’s Wired:
Over the past few years, one of the most important shifts in the digital world has been the move from the wide-open Web to semi-closed platforms that use the Internet for transport but not the browser for display. It’s driven primarily by the rise of the iPhone model of mobile computing, and it’s a world Google can’t crawl, one where HTML doesn’t rule. And it’s the world that consumers are increasingly choosing….
We’ve seen a shift like this before. In the late 90s, consumers adopted the web to search, shop, and socialize. Companies who recognized the shift capitalized (think Google, Amazon, or eBay), and those who couldn't innovate fast enough suffered.
How can consumers reach your service or interact with you on their device (phone/set top/tablet/car/other) of choice? Can your service or data be included or embedded in applications consumers love? What would be the impact if your main competitor’s service was available everywhere and embedded in popular applications and devices?
An open API strategy allows you to engage and capitalize in the multi-device world - and just like we saw in the 90s with websites, companies need to adapt to succeed.
APIs are like a garden hose. They can make things grow.
Well that's what I was thinking as I tried to save my roses from the blistering summer heat here in Dallas, Texas. It really started to make sense when I snapped off my trigger nozzle in favor of a sprinkler. I have the quick connect system so it's a piece of cake to swap out attachments. The 104 degree heat was getting to me, and I started to imagine the hose being connected to retail information and inventory - the API being the quick connect and the nozzles being the interface to consumers.
I'm sitting on the patio at this point, the sprinklers doing the work now, and I'm thinking I should grab a beer and really see where this analogy goes. I watch the sprinkler go back and forth, spraying a pattern of precious water across the lawn - and on my FENCE!
No, the source of life cannot be wasted on a board-on-board fence. I get up and carefully plan my assault on the sprinkler, careful not to get wet (note to self: cold water pelting your body when its 104 is not something you should avoid). The sprinkler has all kinds of adjustment mechanisms. I can adjust the spray pattern left or right, long or short. I can control the amount of water going through the valve and of course there's a timer.
Ahhhhh, this like API infrastructure, the control panel for APIs. Crystal clear. Just like the mechanisms of the garden hose nozzle let your control and target different areas of your lawn, API infrastructure lets you optimize your API for various sections of the market - from mobile developers to affiliate marketers. And just like a great sprinkler system, an API infrastructure lets you scale up to cover your whole "lawn." Finally, API infrastructure provides visibility, letting you see where your services are going and how they are being used.
At its core, an API infrastructure lets you harness and control the power of an API and grow your market, just like a garden hose lets you harness the power of water to grow your lawn.
So you know what I did? The next time I went to talk to a prospect I carried a garden hose, quick connect and sprinkler with me (at least they will remember me).
Analogy complete. No!
One more beer (my answer to Job's "One more thing").
API.... A Profit Interface. Another entry on that soon.
The world of APIs hit me in the fall of 2009.
At the time I was working for a large retailer in the entertainment business and putting together a mobile strategy to leverage our existing assets and systems. Ultimately, I was trying to make it easier for our customers to transact. Too many times customers would enter the retail locations and ask for a product only to be told it was rented out or out of stock. I knew for a fact that the product was somewhere in our supply chain, I only needed a way to get it to the customer.
Initially I thought that the ability to look up realtime inventory at the POS would be a good first step. At least we could locate the product in another store and then hold it for the customer. Better yet, we could make the inventory levels available on our website and iPhone app. Itʼs called "trip assurance" in the retail business; a very nice customer convenience. All this information is good, but how does the customer pull the trigger and transact, and actually get what they want?
The answer was right there in front of us. Transact in one channel and fulfill from another channel. The old endless aisle strategy. Use your e-commerce inventory to fulfill demand in the brick and mortar stores. The opportunities were endless - we also had kiosks and digital delivery.
The tenets of our cross-channel strategy were forged:
- Inventory
- Visibility
- Flexible Fulfillment and Payment
- Order Management
- Account Management
- Consistent Pricing and Promotion
- Item Management
We decided to leverage our e-commerce channel as the platform for the future. We built everything to be reusable. We built the foundation using an API.
Originally I was barely able to search my memory for the meaning of the acronym. An Application Programming Interface. An interface that can tap legacy and modern systems alike, an interface that offered a clean read/write function that could be reused from any and all screens.
We set out to build our API as a means to an end for our mobile strategy. But when we started to blur our vision, we saw something new: inventory, orders, payments, items, price, promotion, fulfillment. It was a point of sale. We discovered we could build our next generation POS by leveraging our new retail API strategy.
Mike Debnar is VP of Business Consulting at Sonoa. He comes to Sonoa from Blockbuster where he led the retail systems organization as Vice President, working closely with operations, merchandising and marketing to implement the company's multi-channel retail strategy.
OAuth 1.0 (the current spec version is 1.0a, which fixes a security problem with 1.0) solves an important problem in the world of APIs -- how one web application can give another application API access without requiring that the user give out their password. OAuth 1.0 solves this problem in a clever way through a secure handshake, via API calls, between the two applications. This has allowed APIs to go in places where they could never go before.
OAuth 1.0 works by ensuring that the API client and server share a token, which is like a username, and a token secret, which is like a password. The client must generate a "signature" on every API call by encrypting a bunch of unique information using the token secret. The server must generate the same signature, and only grant access if both signatures match.
The advantage of this approach is that there is no way to find out the token secret, because it is always encrypted when it's sent over the network, and only the client and server have the keys. It doesn't matter if the data is eavesdropped on a WiFi network in Starbucks or captured by a proxy like Apigee -- there's no way to see the secret, so there's no way to impersonate the client based on what's sent over the network. All of this is done without requiring SSL, since SSL can slow down the client and server alike, and make deployment of the API server more complex.
However, both client and server developers found the complexity of generating and validating signatures to be too much. There are many tricky things that a developer must get right, down to exactly what type of "URL Encoding" is used (it's not exactly the same as it's used in other places). If the client or server makes a single tiny mistake in the signature, it's invalid and it's hard to figure out what went wrong.
OAuth 2.0 promises to simplify this stuff in a number of ways:
1. SSL is required for all the communications required to generate the token. This is a huge decrease in complexity because those complex signatures are no longer required.
2. Signatures are not required for the actual API calls once the token has been generated -- SSL is also strongly recommended here.
3. Once the token was generated, OAuth 1.0 required that the client send two security tokens on every API call, and use both to generate the signature. OAuth 2.0 has only one security token, and no signature is required.
4. It is clearly specified which parts of the protocol are implemented by the "resource owner," which is the actual server that implements the API, and which parts may be implemented by a separate "authorization server." That will make it easier for products like Apigee to offer OAuth 2.0 support to existing APIs.
For these reasons, OAuth 2.0 has already been adopted by companies like Facebook, which uses the draft spec in its Graph API. Of course, it's a new spec, which means there are new requirements and use cases that make it more complex. For instance, OAuth 2.0 also clearly lays out how to use OAuth entirely inside a browser using JavaScript that has no way to securely store a token, and it explains at a high level how to use it on a mobile phone or even on a device that has no web browser at all.
Finally, although the developers of the world will not miss generating OAuth 1.0 signatures, they served a purpose, because they allowed a client to send its token and secret securely to a server without requiring SSL. For APIs and devices that do not want to support SSL for performance or complexity reasons, signatures are still a good choice. Right now, signatures have been removed from the OAuth 2.0 spec, but they'll be added to a separate extension spec at some point.
So should you use OAuth 2.0 today? Here are a few things to consider:
- Spec changes. OAuth 2.0 has not reached a stable IETF draft yet. If you implement it today, are you prepared to change your implementation every few weeks until the committee has agreed on a stable version? OAuth 1.0a, on the other hand, is already a well-defined standard that's not going to change any time soon.
- Implementations. There are a number of code libraries for both client and server that support 1.0a today. There aren't as many for 2.0, so you're going to have to build more stuff on your own.
- Complexity. There's no doubt that 2.0 is easier to implement both on the client and server side.
- Performance. If you are unwilling or unable to use SSL for all of your API traffic, then OAuth 2.0 is not a good choice until some sort of signature extension is added to the spec. OAuth 1.0a already supports signatures, which are complex but allow you to securely exchange tokens without requiring the use of SSL.
You can also check out my blog on "When to Use OAuth" for more, and we'll continue to explore this issue as it evolves.
In our daily talks with customers about their APIs, OAuth has become a major consideration. It's quickly replacing the various proprietary "authentication token" schemes used by early APIs (such as the Amazon Web Services APIs) with a flexible standard; and it solves for new use cases emerging from mashups and Web 2.0. Still, there is a lot of confusion about OAuth out there.
Based on the current state of the technology, we know that there are different API use cases. Depending on your security needs, sometimes OAuth is the only security technology an API can realistically support. In others cases, it may be overkill, or something to add alongside another scheme.
OAuth Overkill?
OAuth is overkill for an API that doesn't require strong authentication. Many "catalog" and "search" APIs that access public data fall into this category. The goal of an API like this is to gain adoption. There's no reason for such an API to require individual users to authenticate to retrieve information from a product catalog, or search public data. (Unless, of course, your API's business model revolves around data that is so valuable that you can get away with charging for every data access. In today's world, that's not common.) A simple API key, however, is a great idea for these kinds of APIs, integrated into your API analytics so you and your developers can see what's going on.
The Case for OAuth
OAuth is the only realistic choice for a web application that itself uses another web application's API on behalf of the user. For instance, consider a web application that integrates with Twitter. (Perhaps it's a geolocation app like Foursquare that offers the ability to tweet where you are and what you're doing.) Today, it is unacceptable for such a web application to store its users' Twitter passwords. OAuth was designed precisely for this use case -- it gives the web app a secure way to get an access token for Twitter, which the user can revoke at any time, without ever revealing that Twitter password to the web app.
Basic Auth- Still Important
In most cases OAuth should be one of two or three security choices for most APIs. Again, consider Twitter. It makes perfect sense for OAuth to be used by other web apps as a way to access Twitter. But Twitter has long supported "Basic" HTTP authentication as well, using a username and a password. While this is bad news for a web application client, for a mobile or a desktop client that is used by an individual user, it's just fine as long as the client takes some care with the password.
And importantly, Basic authentication is easy. If your API requires secure authentication, and you want it to be easy to integrate and test, then offering Basic authentication means that the barrier to entry is low.
Now, once the decision to use OAuth has been made, the question is whether to use the current version 1.0a, or the still-under-development OAuth 2.0. We'll talk about that next.
