OAuth 2.0: Enabling identity for the cloud, mobile
03 March, 2014
category: Corporate, Digital ID, Government
By Paul Madsen, Ping Identity
Digital identity is becoming increasingly important as enterprises strive to protect and control access to online resources. A series of maturing standards is helping make identity management and single sign-on a reality for organizations deploying systems.
As 2013 came to a close SecureIDNews.co
The key technical underpinnings of the cloud – and the emerging Internet of Things – are APIs. Otherwise known as Application Programming Interfaces, APIs provide consistent methods for outside entities, such as server clients and mobile applications, to interact with services and data in the cloud in a clean, standardized manner.
APIs whittle away the underlying complexity of the application, making available to outside clients a well-defined set of possible requests and responses. Because of the advantages they offer for building scalable and available architectures, APIs will be used more to move data, as opposed to browser applications.
Is was only until recently, however, that the security and scalability of APIs were threatened by an authentication and authorization model sometimes called the “password anti-pattern” – a method wherein clients wanting to call an API on behalf of a particular user would collect and replay the password for that user on its calls to the API. This authentication model is characterized as an anti-pattern because it both inappropriately relies on passwords being shared outside the proper context and is unable to support adequate granularity of permissions and revocation.
OAuth 2.0 provides an alternative to this password anti-pattern by defining consistent, flexible authentication, authorization and policy architecture for Web servers, mobile applications and devices attempting to communicate with Cloud APIs.
OAuth 2.0 defines a framework for securing application access to protected resources – often but not solely identity attributes of a particular user – through APIs, most typically RESTful. REST defines a set of architectural principles by which users can design Web services that focus on a system’s resources, including how resource states are addressed and transferred over HTTP from clients writing in different languages.
There are three primary participants in the OAuth flow. OAuth first enables a client – an application that desires information – to send an API query to a Resource Server, the application hosting the desired information, such that the server can verify that the message was indeed sent by a valid client.
The client then authenticates to the Resource Server via the inclusion of an “access token” in its API message, a token previously provided to the client by an Authorization Server.
In those OAuth scenarios in which the API in question protects access to a User’s identity attributes, it may be the case that the access token will be issued by the Authorization Server only after the user has explicitly given consent to the client accessing those attributes.
OAuth offers significant advantages over the password anti-pattern. First, by having the client present a token representing the user and their consent for a given API interaction, rather than the user’s password, the client doesn’t actually need to see or store the password.
Consider, for example, the ‘Nest’ Internet-enabled thermostat. While it may be acceptable to have Nest’s own Android application authenticate it’s API calls to the Nest servers via inclusion of the user’s Nest password – by which the thermostat can be managed, queried, etc. – it would be inappropriate for a third-party application to do the same. Instead, the third-party app should be issued an access token that can have reduced privileges, for example read but not write, and be revoked when desirable.
Large-scale API architectures for the cloud, mobile and Internet of Things are simply not viable without an authentication and authorization model that can scale accordingly. As it were, OAuth 2.0 defines such a framework, and should be a critical piece of the API security toolbox going forward.
