Using a token-based security scheme, the OAuth (or, Open Authorization) protocol has gained exceptional attention of late in the world of services and security. Although somewhat less than a household word, its workings have become very familiar to many households. A particularly notable application that uses OAuth is the Facebook Platform.
Through its use of the token design pattern, OAuth allows Web application users, after an initial set-up dialog, to move from site to site without an additional login. As such, it enables many of the startling application integrations and mashups that give flair to the modern Web. It allows users to permit use of, say, their Facebook name and password without disclosing their Facebook credentials. OAuth use has advanced further as applications have been adapted for Web-connected mobile devices.
Work on standardization and version updates of OAuth is overseen under the aegis of the IETF. Building on work started in 2006 by a Twitter software engineer, an IETF working group that in late 2010 led formalization of v.2.0 included individuals from Microsoft, Facebook, Yahoo and other Web software concerns.
OAuth has become a ready means for moving between sites, and for connecting software services. If the user later decides not to trust a site, the user is able, via profile pages, to revoke permission to pass a token to a site.
By definition, OAuth lets client nodes access server resources on behalf of a “resource owner.” Its user appeal clearly lies in the fact that end-users can authorize third-party access to server sources, without laboriously sharing credentials. For many enterprises, SAML, OpenID, SAML, XRDS, InformationCards/CardSpace, WS-Trust, WS-Security and other identification software services will more completely cover security requirements.
But for enterprises that now support a mix of Web application types, Oauth may play alongside, for example, SAML. OAuth philosophy seems akin to some other “just enough” or “good enough” philosophies. In this case, it is meant to provide adequate security for a huge number of common application design patterns.
While WS-Trust and WS-Security align with SOAP Web-service based application types, OAuth has a natural affinity for REpresentational State Transfer (REST) Web-services-based application types.
OAuth token strings
“Simple” was a stated goal for OAuth. After initial setup, a client sends credentials to an authorization server (at, for example, Facebook.com) that sends back an access token. Subsequently, the client can send HTTP requests with an access token to a resource server (say, LinkedIn.com) which sends an HTTP response. The resource owner can set a time limit on the access that it grants. A refresh token is used when the access token is valid for a shorter time period than the resource owner granted. The ways for obtaining a token can vary according to different client types (such as PC, smart phone, notebook and so on).
The IETF documentation for Oath states that token strings can use any internal structure agreed upon between the authorization server and the resource server, but their structure is hidden to the client and the resource server, which can increase the complexity of debugging for developers. Overall, the developer may find OAuth simplicity somewhat deceptive – in that working with services APIs is still a bit of an art. Interoperability is not guaranteed out of the box - as with any new standard, getting application end points to align can be an iterative process.
Still, OAuth's aptitude for REST opens it up to a broader class of developers other than approaches focused on SOAP, for example.
OAuth has obvious limitations for security-sensitive and mission-critical applications. All a user needs is a name and a password. The user's identity is effectively masked from the resource site. (As in the famous New Yorker cartoon dogs on the Internet can still rest assured that “.. on the Internet, nobody knows you're a dog.”)
OAuth sets simplicity as a goal, and tries to adhere to the “just enough” motto - as in “Let's use just enough security.” But “just enough” has found plenty of uses.