APIs abiertas o un Internet de las cosas inseguro

APIs abiertas o un Internet de las cosas inseguro
APIs abiertas o un Internet de las cosas inseguro

BBVA API Market

Se dice que el corazón vuela siempre más lejos y más rápido que la mente. Tal vez sea una frase demasiado poética si pretendes hablar de APIs, pero es que algo similar sucede con la tecnología y la seguridad. La primera siempre vuela más lejos y más rápido que la segunda. Y eso casi nunca sale gratis. Hoy casi todo el mundo habla del Internet de las cosas, los objetos conectados y las APIs, pero algo menos de la seguridad necesaria en ese entorno de desarrollo y negocio.

Algunos profesionales vinculados a la economía API llevan algún tiempo hablando de que la apertura de los datos y el uso de interfaces de desarrollo de aplicaciones abiertas pueden ayudar al desarrollo de entornos seguros: abrir el campo para que más ojos puedan observar errores, anticiparse a ellos o solucionarlos a tiempo. Uno de ellos es Kin Lane, uno de los evangelistas del uso de APIs abiertas más importantes del planeta, que pasó de dormir en aeropuertos en sus viajes de una ciudad a otra a estar apoyado por tres empresas como 3scale, Restlet y WS02, tres jugadores del mundo de las APIs, el Internet de las cosas y el desarrollo.

Siempre se ha establecido un paralelismo entre los SDK (kits de desarrollo de aplicaciones) para hardware y las APIs, por ejemplo, para el mercado del Internet de las cosas. Las interfaces de desarrollo de aplicaciones, al final, son como SDKs especiales. El problema es que un fallo de seguridad o funcionamiento en un SDK y su efecto en una aplicación se soluciona con una actualización y una descarga, que puede tener un coste de 2 o 3 euros o ser totalmente gratuita. En un objeto conectado, un error en una API puede dar al traste con una inversión mucho más elevada. No existe, ni mucho menos, un margen de maniobra tan amplio.

Espacios para las APIs abiertas

La alianza de Lane y 3scale está liderando grandes avances en el impulso de las APIs abiertas. Lane no solo da charlas de evangelización, también encabeza proyectos interesantes dentro del ecosistema abierto de APIs, que en muchas ocasiones mejoran la seguridad de los productos finales. Un ejemplo es API Commons, una plataforma donde cualquier desarrollador puede poner su interfaz de desarrollo de aplicaciones bajo licencia Creative Commons (CC BY-SA o CC0) para que otros profesionales puedan usarla libremente y mejorarla como deseen.

Los otros dos proyectos más importantes son:

– APIs.json: un formato para documentar APIs (licencias, precios, políticas y especificaciones técnicas y empresariales). Es una forma sencilla de facilitar el trabajo previo a los desarrolladores que buscan usar una API para el desarrollo de una aplicación o para conectar objetos dentro del IoT. Existe un paralelismo evidente entre APIs.json y el sitemap.xml de una página web. Lane y 3scale tienen su propio generador de formatos API.json para APIs.

– APIs.io: es un gran buscador de web APIs. Ahora existe un repositorio con un volumen de 1.029 interfaces de desarrollo de aplicaciones. Lógicamente, cada una de esas APIs están descritas mediante un formato API.json.

Protocolos de seguridad: OAuth2

OAuth2 es un marco de creación de protocolos, más que un protocolo en sí mismo. Empresas como Google, Facebook, Microsoft o Twitter ya están usando OAuth2 como sistema de autorización y seguridad para el uso de sus APIs por terceros. Los protocolos habituales cuando una empresa desarrolla una API son una clave API o credenciales típicas como un usuario y contraseña. Ese tipo de recursos tienen algunos problemas de seguridad, por ejemplo, en aplicaciones de página única (SPA), basadas en el lado del servidor. En estos casos, cualquier desarrollador podría acceder a las credenciales desde el navegador. Una puerta de entrada.

OAuth2 permite que terceros puedan conectarse a los datos de una aplicación sin necesidad de disponer de las credenciales de usuario y contraseña.  Lógicamente, ese acceso a los datos, pleno o parcial, puede ser revocado en cualquier momento porque los privilegios de acceso, igual que los roles de usuario, son modificables. El sistema de seguridad OAuth2 se basa en lo que se conoce como token de acceso y permite la interacción con los sistemas propios sin facilitar esas credenciales.

¿OAuth2 es un sistema sin riesgos de seguridad? Evidentemente no. De hecho, el grado de seguridad que ofrece OAuth fue motivo de fricción con Eran Hammer, uno de los padres de la especificación. Hammer sostuvo en su momento que OAuth2 era “más complejo e incompleto” y “menos seguro, interoperable y útil” que OAuth1, sobre todo en aplicaciones móviles nativas, y de ahí su ruptura con el grupo IETF, responsable final del proyecto OAuth2. El punto de partida con este protocolo es limitado y, si un equipo de desarrolladores quiere usarlo para dar acceso a su API, lo más recomendable es disponer de experto en seguridad.

Ventajas de OAuth2

Un sistema de credenciales tiene algunos problemas con respecto a OAuth2:

– Para un protocolo basado en credenciales de usuario y contraseña son necesarios servidores que soporten la autenticación por contraseña. En el caso de OAuth, el servidor de autenticación mediante token de acceso puede ser distinto del servidor que aloja los recursos protegidos para su uso.

– Con este sistema de seguridad, las aplicaciones de terceros disponen de un acceso a los recursos demasiado amplio, lo que debilita y mucho la posición de protección y seguridad del propietario de la API y los datos. No es posible, por desgracia, limitar el acceso ni en duración ni en volumen.

– Si alguien plantear revocar el acceso de un tercero, necesariamente debe restringírselo a todas las aplicaciones de terceros que trabajen con la API porque solo es posible restringir el acceso con el cambio de contraseña. En el caso de OAuth, cada usuario dispone de un token de acceso, que puede ser revocado o restringido de forma individual sin que afecte al resto.

Más información sobre APIs aquí.

Síguenos en @BBVAAPIMarket

También podría interesarte