Cloud providers and many federated IAM practitioners are excited about OAuth, a new(ish) security technology on the scene. I’ve written about OAuth in Protecting Enterprise APIs With A Light Touch. The cheat-sheet list I keep of major OAuth product support announcements already includes items from Apigee, Covisint, Google, IBM, Layer 7, Microsoft, Ping Identity, and salesforce.com. (Did I miss yours? Let me know.)
OAuth specializes in securing API/web service access by a uniquely identified client app on behalf of a uniquely identified user. It has flows for letting the user explicitly consent to (authorize) this connection, but generally relies on authorizing the actions of the calling application itself through simple authentication. So does the auth part of the name stand for authentication, authorization, or what? Let’s go with “all of the above.”
However, OAuth is merely plumbing of a sort similar to the WS-Security standard (or, for that matter, HTTP Basic Authentication). It doesn’t solve every auth* problem known to humankind, not by a long shot. What other IAM solutions are popping up in the API-economy universe? Two standards communities are building solutions on top of OAuth to round out the picture:
Microsoft announced during last week's RSA conference that it would not be shipping Windows CardSpace 2.0. A lot of design imperatives weighed on that one deliverable: security, privacy, usability, bridging the enterprise and consumer identity worlds – and being the standard-bearer of the "identity metasystem" and the "laws of identity" to boot. Something had to give. What are the implications for security and risk professionals?
The CardSpace model had nice phishing resistance properties that cloud-based identity selectors will find hard to replicate, alas. But without wide adoption on the open Web, that wasn't going to make a dent anyway. We'll have to look for other native-app solutions over time for that.