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. . .