Open APIs or the insecure Internet of Things

Open APIs or the insecure Internet of Things
Open APIs or the insecure Internet of Things


It is said that the heart always flies further and faster than the mind. Perhaps that phrase is too poetic if you want to talk about APIs, but in fact something similar happens with technology and security: the former always flies further and faster than the latter. And there’s almost always a price to be paid. Today nearly everyone talks about the Internet of Things, connected objects and APIs, but rather less about the security needed in this development and business environment.

Some professionals linked to the API economy have been talking for some time about the fact that opening up data and using open application development interfaces could help the development of secure environments by opening up the field so that more eyes can discover errors, anticipating them or resolving them in time. Among them is Kin Lane, one of the most important evangelists on the planet of the use of open APIs. His time sleeping in airports during his trips from one city to another are behind him. He is now supported by companies such as 3scale, Restlet and WS02, three players in the world of APIs, the Internet of Things and development.

He has always established a parallelism between the SDK (software development kits) for hardware and APIs, such as those for the Internet of Things market. After all, application development interfaces are like special SDKs. The problem is that if there is a security or operations fault in an SDK, its effect on an application is resolved with an update and a download, which could cost 2 or 3 euros or be completely free. In a connected object, an error in an API could bring disaster to a much more expensive investment. The room for maneuver is far from being the same.

Spaces for open APIs

The alliance between Lane and 3scale is leading major progress in boosting open APIs. Lane not only gives talks on his evangelizing mission, he also heads up interesting projects within the open API ecosystem, which in many cases improve the security of the final projects. One example is API Commons, a platform on which any developer can put his API under a Creative Commons License (CC BY-SA o CC0) so that other professionals can use it freely and improve it if they wish to.

The other two most important projects are:

– APIs.json: a format for documenting APIs (licenses, prices, policies and technical and business specifications). It is a simple way of facilitating the initial work for developers who aim to use an API to develop an application or to connect objects within the IoT. There is an obvious parallelism between APIs.json and the sitemap.xml of a website. Lane and 3scale have their own generator of API.json formats for APIs.

– a great search engine for APIs on the web. There is now a repository with a volume of 1,029 APIs. Of course, each of these APIs is described through an API.json format.

Security protocols: OAuth2

OAuth2 is a framework for creating protocols, rather than a protocol in itself. Companies such as Google, Facebook, Microsoft and Twitter area already using OAuth2 as an authorization and security system for third-party use of their APIs. The normal protocols when a company develops an API are an API key or typical credentials such as username and password. These types of resources have some security problems, for example, in single page applications (SPA) based on the server side. In these cases, any developer can access the credentials from the browser: it’s a gateway.

OAuth2 allows third parties to connect to an app’s data without the need to have user credentials and a password.  Of course, this full or partial access to data may be revoked at any time because access privileges, like user roles, can be modified. The OAuth2 security system is based on what is known as an access  token and allows interaction with own systems without having to make these credentials available.

Is OAuth2 a system without security risks? Obviously not. In fact, the level of security offered by OAuth was the cause of a dispute with Eran Hammer, one of the creators of the specification. Hammer claimed at the time that OAuth2 was “more complex and incomplete” and “less secure, interoperable and useful” than OAuth1, above all in native mobile applications, and that is the reason for his break with the IETF group, which is basically responsible for the OAuth2 project. The starting point with this protocol is limited, and if a team of developers wants to use it to provide access to its API, ideally they should have a security expert available.

Advantages of OAuth2

A system using credentials has some problems compared with OAuth2:

– A project based on user credentials and a password needs servers to support password identification. In the case of OAuth, the server using authentication by an access token may be different from the server that stores the protected resources for their use.

– With this security system, the access of third-party applications to resources is too wide-ranging, which greatly weakens the protection and security position of the owner of the API and the data. Unfortunately, it is not possible to limit access either in terms of duration or volume.

– If you want to revoke access to a third party, you must restrict it to all third-party applications that work with the API because it is only possible to restrict access with a change of password. In the case of OAuth, each user has an access token that may be revoked or restricted individually, without this affecting the rest.

More information on APIs here.

Follow us on @BBVAAPIMarket

It may interest you