Protecting Internal APIs — Is OAuth Ready For Its Closeup?

Two years ago, the OAuth API protection mechanism was a fairly well-kept secret. It actually won an award at the 2009 European Identity Conference for "best new/improved standard," but most people didn't seem to have figured out what it was good for yet; I felt like I was the only one even talking about it.

Fast forward a bit, when Facebook started using an early draft of OAuth 2.0 in its Open Graph-based platform, and then a bit more, when Twitter started requiring OAuth 1.0a use by third-party developers (known amusingly as the OAuthcalypse), turning off the HTTP Basic authentication option. And now we're in a world where cloud developers talk casually about the "open API economy" and the ease of getting work done by building RESTful apps, and OAuth is making star appearances in recent gatherings of influential software architects and developers I've attended, such as The Experts Conference and the Internet Identity Workshop.

I've observed that a number of enterprises have quietly hit upon using OAuth for their internal (RESTful, natch) web service environments — and that they're starting to get their arms around their internal SOA landscape by seeing it as an API economy. (Phil Hunt of Oracle nails this zeitgeist in his blog post musing on lightweight web services.) While middleware vendors race to get OAuth tooling support out, a lot of devs are just doin' it for themselves.

So I’ve set out to research the phenomenon of internal OAuth use, with the help of my colleague Alex Crumb, in something of an "open-source" manner: through social media. That's where you come in, dear security-and-risk-professional reader. Won't you share your thoughts here on the following?

  • Are you finding greater numbers of "rogue" RESTful apps being created in your enterprise? What’s the awareness level among these devs about the need to secure API access? Are some apps making their way to cloud platforms like Google App Engine without adequate security?
  • What levels of OAuth use are you seeing internally now? What other methods is it supplanting and why? (I hear a lot about hardcoded client IDs and passwords that are supposed to be rotated frequently but rarely are. I also hear about poor WS-Security performance at huge scale.)
  • Any other best, worst, or at least amusing practices to share?

The colloquial term for plain old OAuth-protected client-server communications is "two-legged OAuth" –  and I keep finding people slipping back into this usage, although no one likes it (recently suggested alternative: hands!). So, if you'd like to share thoughts on Twitter, just make sure to use the hashtag #Forr2Legs so Alex and I, and everyone, can follow along.

UPDATED 05.17.11: Our active discussion on the Forrest S&R Community has just gotten going, where we're focusing on the sudden rise of mobility in our app landscape, a very hot trernding topic we received several questions on over Twitter! The link is now active, follow us as the conversation continues. . .

Categories:

Comments

For developers and deployers...

Using OAuth securely is still a bit of a challenge. OAuth's incredible flexibility means there are still a lot of choices and decisions that developers and deployers have to make to get things right for their scenarios.

The good news is that OAuth is securable and the core spec will soon have a new security considerations section targeted at implementers (current draft of implementer security considerations here: http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsideration... ). There is also a longer specification (http://tools.ietf.org/html/draft-lodderstedt-oauth-security-01) for deployers.

If I had one rule of thumb? Make sure you use server-side TLS on all OAuth operations. If TLS is a real problem for your enterprise, I'm interested in hearing more about your use case. Remember, don't forget the 'S' in HTTPS! ;-)

Framework specifications

Phil, thanks for weighing in and providing the latest links. You make a good point; OAuth, like many specs, is more of a framework than a single protocol per se. Every "MAY" or "SHOULD" in a spec makes it branch out, and capturing these deployment choices is important.

A big "+1" to your HTTPS reminder. Interestingly, Facebook just announced a commitment to requiring its third-party developers to acquire SSL certs. (That's not quite the same use case as intra-enterprise, but encouraging nonetheless.)

Final report is out

For folks following this post, I just wanted to let you know that the final report is out. Happy reading (if you're so inclined)!

http://forr.com/oauth2011