What does that mean? Don’t panic. The consequences of a client application’s key being compromised is as serious as user credentials being compromised.

The risk associated with this breach is that a malicious application tricking you into participating in an OAuth handshake (phishing) could access the twitter API on your behalf.

Attackers might come up with clever ways to exploit this leak. In the meantime, avoid using twitter through any application other than the twitter application itself.

OAuth distinguishes between confidential and public clients.

Applications that you can publicly download on your own device (mobile or not) fall in the public category because they are subject to their embedded secret being reverse engineered as probably happened in this case. This incident is a good illustration of the fact that client secrets should not form the basis of a secure session in public clients like mobile applications because, well, those secrets are easily discovered.

Twitter may create new keys for their application and look for ways to better obfuscate them but it’s only a matter of time before these new secrets are also compromised.

As I discussed at Cloud Security Alliance and in our last Tech Talk, authentication involving redirection between applications on mobile device has its risks.

There are ways to completely secure this between applications of a same domain but solving this across 3rd party mobile apps, in a fool-proof way requires either something like a multi-factor authentication or the provisioning of client secrets post-application download which is often not practical.

Either way, API and application providers would do well not relying on pseudo-secrets embedded in publicly available applications as the basis of any security.

In the case of client applications issued by the same provider as the API they consume (e.g. the official twitter app), the password grant type make a lot more sense to me and provides a better UX.

But how do enterprises balance access control with the individual’s right to choose the apps they want? How do enterprises grant access to sensitive on-premise data via mobile devices without compromising security?

Enterprises need secure ways to surface internal information assets in mobile ready formats that can be easily consumed by both mobile developers and the apps they create. They need simplified ways to manage how enterprise applications and systems get exposed to mobile developers and apps.

Layer 7′s new SecureSpan Mobile Access Gateway does just that by streamlining the process of adapting internal data, application and security infrastructure for mobile use. Delivered as a policy pack extension to our SecureSpan API Proxy/SOA Gateway, the Mobile Access Gateway provides a centralized way to control security and management policies for information assets exposed via APIs to mobile developers and apps.

Contest: Win a $250 Amazon Gift Card
To celebrate the general availability of the SecureSpan Mobile Access Gateway, we’re having a Twitter contest and giving away a $250 Amazon gift card.

Here’s how to enter:

1. Retweet the following:

Win a $250 Amazon gift card from @layer7  http://ow.ly/cFj9i #L7MAG RT to enter!

Tweet This for a Chance to Win

2. Don’t have twitter and still want to enter? Just leave a comment on this post, telling us your favorite mobile app.

The contest ends Aug 8 at noon. The winner will be drawn at random. If you win, we’ll send you a direct message on Twitter to let you know.

Answer: Neither —  they are really only useful as a whole. A client without a server is usually little more than an non-functional wire frame and a server without a client is simply unrealized potential. Bring them together though and you have something of lasting value. So, neither matters more and each actually matters a lot less than half.

In the API world, this is an easy point to miss. The server side always wields disproportionate power by virtue of controlling the API to its services and this can easily foster an arrogance about the server’s place in the world. This effect is nicely illustrated by Twitter’s recent missteps around developer management.

The problems for Twitter all began with a blog entry. Blogs are the mouthpiece of the platform. Tucked away within an interesting entry about Twitter Cards and the potential to run applications within tweets (something that is genuinely exciting), can be found a restatement of an early warning to developers:

“(D)evelopers should not ‘build client apps that mimic or reproduce the mainstream Twitter consumer client experience.’”

Ominous stuff indeed. This was quickly picked up on by Nick Bilton writing in the New York Times Bits blog, who pointed out that the real problem is that Twitter just isn’t very good at writing client-side apps that leverage its own API. Stifling competition by leveraging the API power card can only alienate developers — and by extension the public, who are left with a single vendor solution. Suddenly, it feels like the 1980s all over again.

This ignited a firestorm of concern that was well summarized by Adam Green on ProgrammableWeb. Green acknowledged that API change is inevitable but pointed out that this is something that can be managed effectively — which is not what Twitter is doing right now.

The irony of the whole thing is that, in the past, by exercising its power position, Twitter has actually made great contributions to the API community. In mid 2010, Twitter cut off basic authentication to APIs in favor of OAuth, a drop-dead event that became known as the OAuthcalypse. Hyperbole aside, in terms of actual impact on the populace, this cut over made even Y2K look like the end of days. Given a tractable challenge, developers cope, which is really Green’s point.

What is important to realize is that API Management isn’t technical but social. Win the community over and they will move mountains. Piss them off and they will leave in droves for the next paying gig.

The thing I always remind people is that as a trend, APIs are not about technology; they are a strategy. Truth is, the technology is pretty easy — and that’s the real secret to API’s success. You see, the communications are never the thing; the app is the thing (and that is what WS-* missed). Maintaining simplicity and a low barrier to entry counts for everything because it means you can get on with building real apps.

Now, I can give you the very best infrastructure and tools to facilitate API community. But how you manage this community… Well, that is where the real work begins and — in the end — it’s all a lot less deterministic than we technologists like to admit. People are hard to manage but communities are even harder.

If there is a lesson here, it is that APIs are really about potential and that potential can only be realized when you have two sides — client and server — fully engaged. Mess this one up and you’re left with just a bunch of unused interfaces.