Métodos de seguridad de la información para proteger la comunicación y los datos de servicios web REST en peticiones HTTP utilizando JSON Web Token y Keycloak Red Hat Single Sign On

Abstract

Abstract: Currently the protocols and open standards that are used to exchange data between applications or systems are web services. REST is the most used Internet services API due to the logic and ease of exchanging data, however, this technology is using the non-secure HTTP protocol as a means of communication compromises the information it manages. Keywords: Jwt; Openid-connect; Security-domain; Postman; Auth. 1.Introducción La tecnología está alterando fundamentalmente la forma en la que los seres humanos desarrollamos nuestras actividades diarias haciéndolas cada vez más automatizadas, más rápidas y más productivas. Es así que este artículo empezará identificando la problemática de seguridad en la comunicación e intercambio de datos en peticiones HTTP, se evaluará alternativas de mitigación a las vulnerabilidades detectadas al utilizar web services REST sobre el protocolo HTTP y por último se formulará métodos de seguridad de la información que permitan proteger la comunicación y los datos de servicios web REST en peticiones HTTP utilizando Json Web Token y Keycloak Red Hat Single Sign On. 2.Problemas de seguridad API REST La seguridad en Internet es un tema que se ha debatido cada vez con mayor frecuencia en blogs y foros de tecnología y con una razón valedera: las numerosas infracciones de seguridad de alto perfil han crecido significativamente en los últimos años.

Headnote

Resumen: Actualmente los protocolos y estándares abiertos que se utilizan para intercambiar datos entre aplicaciones o sistemas son los servicios web. REST es la API de servicios de internet más utilizada debido a la lógica y facilidad para intercambiar datos sin embargo esta tecnología al utilizar el protocolo no seguro HTTP como medio de comunicación compromete la información que gestiona. Este artículo identifica alternativas de mitigación a las vulnerabilidades que surgen al utilizar web services REST sobre el protocolo HTTP, a través de una combinación de las tecnologías JSON Web Token y Keycloak Red Hat Single Sign On se formula métodos de seguridad de la información que permiten proteger la comunicación y los datos de servicios web REST en peticiones HTTP. Se exponen los resultados obtenidos al realizar pruebas con la solución planteada y se compara los hallazgos generados con artículos similares.

Palabras-clave: Jwt; Openid-connect; Security-domain; Postman; Auth.

Abstract: Currently the protocols and open standards that are used to exchange data between applications or systems are web services. REST is the most used Internet services API due to the logic and ease of exchanging data, however, this technology is using the non-secure HTTP protocol as a means of communication compromises the information it manages. This article identifies mitigation alternatives to the vulnerabilities that arise when using REST web services over the HTTP protocol, through a combination of JSON Web Token and Keycloak Red Hat Single Sign On technologies, information security methods are formulated to protect REST web services communication and data in HTTP requests. The results obtained when testing with the proposed solution are presented and the findings generated are compared with similar articles.

Keywords: Jwt; Openid-connect; Security-domain; Postman; Auth.

1.Introducción

La tecnología está alterando fundamentalmente la forma en la que los seres humanos desarrollamos nuestras actividades diarias haciéndolas cada vez más automatizadas, más rápidas y más productivas. Se espera que este avance constante de desarrollo tecnológico crezca significativamente sin embargo aún es incierto que pasará en el futuro, por lo que la respuesta a estos cambios debe ser de manera integral involucrando a todos los interesados desde los sectores público y privado hasta la academia y la sociedad civil.

La cuarta revolución industrial acuñada por el economista y empresario alemán fundador de Foro Económico Mundial Klaus Martin Schwab menciona que el mundo se prepara para avances tecnológicos muy importantes en varios campos como la inteligencia artificial, la robótica, el internet de las cosas, los vehículos autónomos, la impresión 3D, la nanotecnología, la biotecnología, la ciencia de los materiales, el almacenamiento de energía y la computación cuántica (Schwab, 2016). La velocidad de los avances actuales no tiene precedentes históricos. En comparación con épocas anteriores, el desarrollo tecnológico que estamos viviendo está evolucionando a un ritmo impresionante. Estos cambios están afectando a casi todas las industrias en todos los países. Lo que desencadenará de manera segura una mejora significativa en los sistemas de producción, gestión y gobierno.

Actualmente la colección de estándares y protocolos abiertos que se utilizan para intercambiar datos entre aplicaciones o sistemas son los servicios web, debido a la facilidad para intercambiar datos a través de redes de computadoras. REST es el estándar más lógico, eficiente y habitual en la creación de APIs para servicios de internet lo que ha ocasionado que la gran mayoría de aplicaciones y sistemas utilicen una API REST para la creación de servicios de comunicación y transferencia de datos. Twitter, Facebook, YouTube entre otras empresas generan ganancias gracias a las APIs REST. El no contar con esta tecnología, todo el crecimiento de las grandes empresas sería prácticamente imposible.

Sin embargo REST tiene vulnerabilidades similares a las de una aplicación web. Datos de tarjetas de crédito, registros de salud, información financiera, información comercial y muchas otras categorías de información personal necesitan protección, establecer las identidades de los usuarios antes de que accedan a recursos tecnológicos es una característica clave para la seguridad de la información más aún cuando se interactúa con servicios que se comunican a través del protocolo no seguro HTTP.

Existen estudios atacando la misma problemática como el realizado por (ANAYA LOPEZ, 2011) en el cual se comparte las características de intercambio de información y los niveles de apertura que tienen los servicios web, como una herramienta para integrar aplicaciones, intercambiar información y realizar transacciones electrónicas en internet. Se evaluará la propuesta de solución y el procedimiento detallado que se propone para resolver los problemas de seguridad haciendo uso de los estándares WS-Security, XML Signature, XML Encryption y SAML.

(Guamán Quinche, 2011) nos expone que generalmente los ataques informáticos en la web se dan en la capa de aplicación y que estos constituyen el 60% de los intentos observados en internet contra aplicaciones web por lo que se propone la utilización de un servidor proxy situado en el servidor de aplicaciones con la finalidad de filtrar el flujo de datos de entrada y salida. Dicho proceso de filtrado tiene en cuenta un conjunto de políticas de seguridad diseñada por los desarrolladores de las aplicaciones Web.

(Christie et al., 2017) nos menciona que establecer las identidades de los usuarios antes de que accedan a recursos de infraestructura es una característica clave para los sistemas informáticos por lo que este artículo examina el uso de Keycloak como implementación de un sistema de gestión de identidad para middleware que sirva como reemplazo a una solución de WSO2.

La seguridad de la información permite gestionar los activos de información y controlar de mejor manera sus riesgos, en relación al impacto que representan para una organización. En tal sentido a pesar de que existen estudios relacionados es indiscutible el aporte que se pueda generar a partir de esta investigación.

Es así que este artículo empezará identificando la problemática de seguridad en la comunicación e intercambio de datos en peticiones HTTP, se evaluará alternativas de mitigación a las vulnerabilidades detectadas al utilizar web services REST sobre el protocolo HTTP y por último se formulará métodos de seguridad de la información que permitan proteger la comunicación y los datos de servicios web REST en peticiones HTTP utilizando Json Web Token y Keycloak Red Hat Single Sign On.

2.Problemas de seguridad API REST

La seguridad en Internet es un tema que se ha debatido cada vez con mayor frecuencia en blogs y foros de tecnología y con una razón valedera: las numerosas infracciones de seguridad de alto perfil han crecido significativamente en los últimos años. La seguridad es de gran importancia, especialmente en el mundo de las API REST.

En la Figura 1 podemos observar que la mayoría de las organizaciones encargan a sus desarrolladores escribir y administrar APIs. Mientras que el 33 por ciento usa tecnología dedicada para administrar sus APIs, el 90 por ciento de los encuestados se apoya en sus equipos de desarrollo o recursos externos para codificar las API desde cero exigiendo a sus desarrolladores demandas adicionales para crear y administrar APIs para el negocio.

Los problemas de seguridad deben ser un aspecto importante a tener en cuenta cada vez que se diseña, prueba e implementa una API REST. Con el desarrollo en aumento de las API REST, los niveles de seguridad, la mayoría de las veces, se subestiman en el diseño y desarrollo de la API. La seguridad de los datos confidenciales, ya sea información organizacional o personal, es un factor importante que preocupa a los desarrolladores hoy en día. Las API REST no son una excepción, ya que forman parte de sistemas esenciales que requieren protección contra amenazas e infracciones de seguridad

REST generalmente usa HTTP como su protocolo de comunicación, lo que plantea el conjunto habitual de problemas de seguridad:

* Un posible atacante tiene control total sobre una solicitud o respuesta HTTP cuando es interceptada. Dado que las API REST se usan comúnmente para intercambiar información y posiblemente se ejecuta en muchos servidores, podría dar lugar a muchas brechas invisibles y fugas de información.

* El atacante podría estar en el lado del cliente (consumidor de API REST) o en el lado del servidor si el atacante logra obtener el control sobre el servidor, donde puede crear una aplicación maliciosa. La víctima, en este caso, es la aplicación que consume recursos de servicios remotos.

* Para una aplicación que utiliza REST como cliente o servidor, el otro lado generalmente tiene control total sobre la representación de recursos y podría inyectar cualquier carga útil para atacar el manejo de recursos (como obtener código fuente o ejecución de comandos del sistema).

* Nula depuración de datos de entrada, al no usar ninguna validación no sabemos si recibimos el tipo correcto de variables que se pasan a nuestra API. La información recibida podría ser parte de un ataque Cross Site Scripting (XSS) o podría contener sentencias SQL o comandos maliciosos del sistema operativo.

La implementación de un control de acceso eficiente permite otorgar funcionalidades y contenidos únicamente a aquellas con autorización de hacerlo. El no poseer esta característica o implementarla de manera inadecuada puede permitir al atacante obtener el control de las cuentas de otros usuarios, alterar los privilegios de acceso, cambiar los datos, etc.

El acceso no autorizado a las aplicaciones de la empresa tiende a darse cuando los desarrolladores no configuran correctamente la accesibilidad a nivel de software, lo que genera vulnerabilidades de acceso. El acceso denegado es la consecuencia más conocida de los controles de acceso vulnerados y la explotación del control de acceso es el arte principal de los atacantes. El control de acceso generalmente es productivo si se implementa en una API confiable del lado del servidor, por lo que el atacante no podrá alterar los metadatos del control de acceso.

3.Materiales

3.1. Keycloak

Keycloak es un proyecto de código abierto desarrollado y mantenido por la Comunidad RedHat. Es una solución de gestión de acceso e identidad de código abierto dirigida a aplicaciones y servicios modernos. Facilita la protección de aplicaciones y servicios con poco o ningún código (El Hajj Hussein, 2019).

Ofrece un amplio conjunto de características, como inicio de sesión único, autenticación, autorización, inicio de sesión social, autenticación multifactor y administración centralizada de usuarios. Se listan las siguientes funcionalidades:

* Single Sign On

* Puente Kerberos

* Cortaje de identidad e inicio de sesión social

* Federación de usuarios

* Adaptadores cliente

* Consola de administración

3.2. JSON Web Token

JSON Web Token (abreviado JWT) es un estándar abierto basado en JSON propuesto por IETF (RFC 7519) para la creación de tokens de acceso que permiten la propagación de identidad y privilegios (Bradley, Sakimura, & Jones, 2015).

Esta tecnología define una forma compacta y autónoma para transmitir de forma segura información entre las partes como un objeto JSON. Esta información es verificada y confiable ya que se encuentra firmada digitalmente. Los JWT se pueden firmar usando un secreto (con el algoritmo HMAC) o un par de claves públicas / privadas usando RSA.

JSON Web Token es un método compacto y autónomo para transmitir información, se basa en una cadena de texto que tiene 3 partes (Header, payload, signature) codificadas en Base64, separadas por un punto que es estregado a los clientes de una API como llave de acceso. Keycloak utiliza JWT para transmitir una llave secreta de acceso a usuarios con privilegios.

3.3. REST API

Se utiliza API REST como medio de prueba para ejecutar peticiones HTTP que posteriormente serán aseguradas con un Json Web Token emitido por Keycloak. La arquitectura REST enfoca a todo lo que lo conforma como un recurso. Los servicios web REST son livianos, altamente escalables y mantenibles. Se usan muy comúnmente para el intercambio de información, es el estándar más lógico, eficiente y generalizado en la creación de API para servicios de internet.

3.4. Maven

En esta investigación, para la construcción del aplicativo web que expone el servicio web REST se utiliza maven como herramienta de gestión del proyecto web, maven posee un repositorio global que proporciona las dependencias necesarias para la construcción y compilación de este ejemplo. Utilizar esta herramienta nos ayuda a enfocarnos netamente en la funcionalidad del aplicativo a desarrollar, las bibliotecas, jars necesarios y la forma de compilación del aplicativo se detallan en el archivo pom.xml.

3.5. Jboss EAP

Para exponer el servicio web REST en este ejemplo se utiliza JBoss EAP 7.0 versión que incluye ventajas como una estructura modular que permite habilitar servicios solo cuando es necesario, mejorando la velocidad de inicio, consola de administración basada en web y la interfaz de línea de comando de administración (CLI) que hacen que la edición de archivos de configuración XML sea innecesaria y agregan la capacidad de realizar scripts y automatizar tareas. Además, Jboss EAP incluye APIs para desarrollar rápidamente aplicaciones Java EE seguras y escalables. (Augsten, 2018)

3.6. Eclipse IDE

Se utiliza Eclipse Photon versión 4.8.0 para escribir, ejecutar, navegar y depurar código Java necesario para la construcción de la API REST. Eclipse proporciona herramientas y marcos extensibles que abarcan el ciclo de vida del desarrollo de software, incluido soporte para modelado, entornos de desarrollo de lenguaje para Java, C / C ++entre otros, pruebas y rendimiento, inteligencia empresarial, aplicaciones de cliente enriquecido y desarrollo integrado.

3.7. Postman

Postman es una herramienta para realización de pruebas de servicios web. Ofrece una interfaz de usuario para realizar peticiones hacia una API, evita la molestia de escribir código exhaustivo al diseccionar la funcionalidad de una API. Se utiliza Postman en esta investigación para realizar peticiones HTTP a la API REST creada y de esta manera validar el aseguramiento del servicio web y el acceso no autorizado al mismo.

4.Métodos

4.1.Escenario inicial - consumo servicio web REST no seguro

Para esta demostración se va a construir un servicio web REST expuesto en un servidor JBOSS EAP 7.0 que será consumido por un cliente bajo el siguiente escenario.

El cliente hará peticiones HTTP al servicio web y este responderá enviando información al cliente. En este escenario se ilustra un flujo no seguro de intercambio de información ya que el servicio web responderá todas las peticiones que se soliciten sin ninguna distinción.

4.2.Escenario final - consumo servicio web REST seguro

Para asegurar el consumo del servicio web se utiliza Keycloak 7.0 para que a través de una configuración en el servidor de aplicaciones Jboss EAP 7.0 solicitar un JSON Web Token válido con autorización de consumo al recurso (web service) a toda aquella petición HTTP realizada al REST expuesto.

Este flujo nos permite asegurarnos que solo los usuarios a los que se les otorgó el acceso al servicio web puedan consumir dicha API. De esta forma se evita el acceso no autorizado a información que se transmite bajo un protocolo no seguro como lo es el protocolo HTTP.

4.3.Creación de API REST

Para la creación de la API REST se utiliza el arquetipo "maven-archetype-webapp", se crea la clase que contiene lógica de procesamiento y exposición de información por la API. En este ejemplo el servicio creado tiene un método llamado "obtenerCliente" que expone información de clientes ficticios.

Configuración de archivo web.xml para definir ruta por la cual el servicio web REST creado escuchará peticiones HTTP.

Se edita el archivo "standalone-full.xml" del servidor de aplicaciones Jboss, para agregar etiqueta deployments con la información necesaria para desplegar API REST.

Al iniciar el servidor la API REST está disponible y esperando peticiones en la URL: http://localhost:8180/rest-app/services/privado/Cliente/obtenerClientes.

4.4.Prueba consumo REST no seguro

Con el fin de corroborar que la API REST creada esté funcionando se realiza una petición HTTP bajo el método GET al servicio web.

Como se puede observar la petición realizada al método "obtenerClientes" del servicio web REST devuelve información de manera exitosa. En este estado la API REST es insegura ya que cualquier persona podría obtener datos del servicio únicamente invocando a la URL del mismo.

4.5.Instalación y configuración de keycloak

Para la instalación y configuración de keycloak se sigue la guía de la siguiente web: https://www.keydoak.org/docs/latest/getting_started/index.html. Se realiza las siguientes configuraciones:

1. Creación de usuario administrador

2. Creación de REALM

3. Configuración de cliente keycloak

4. Creación de usuario para obtención de token

5. Creación de cliente keycloak para obtención de token

Adicionalmente se realiza las siguientes configuraciones en el servidor de aplicaciones Jboss EAP 7.

Instalación de los siguientes módulos

1. keycloak-adapter-core

2. keycloak-adapter-spi

3. keycloak-adapter-subsystem

4. keycloak-authz-client

5. keycloak-common

6. keycloak-core

7. keycloak-jboss-adapter-core

8. keycloak-servlet-oauth-client

9. keycloak-wildfly-adapter

En la sección security-domains del archivo standalone-full.xml se agrega dominio de seguridad de keycloak.

La configuración XML de cliente keycloack se lo inserta como "subsystem" dentro de la etiqueta "profile" del archivo standalone-full.xml. Únicamente se modifica el nombre del artefacto a ser asegurado el cual se llama "rest-app.war" correspondiente al nombre de la API REST creada.

4.6.Aseguramiento de API REST

Para asegurar API REST es necesario agregar en el pom.xml principal del proyecto dependencia keycloak en la versión 7.0.0, adicionalmente es necesario agregar restricción de seguridad en el archivo web.xml de la aplicación tal y como se muestra en la Figura 11.

4.4.Prueba fallida consumo REST seguro sin token de autorización

Con el fin de probar que la API REST está rechazando solicitudes sin autorización se realiza una petición HTTP bajo el método GET al servicio web.

Como se puede observar la respuesta a la petición realizada al web service es fallida y devuelve un código 401 "Unauthorized" el cual nos indica que no estamos autorizados a acceder a la API REST.

4.5. Obtención de token para consumo de REST seguro

En la herramienta Postman creamos una petición HTTP a hacia el REALM "Demo-jwt" de Keycloak bajo el método POST.

Al presionar el botón enviar con los datos descritos obtendremos la siguiente respuesta, un objeto JSON con algunos atributos como el token de autorización, el tiempo de expiración es de 5 minutos.

4.6.Prueba exitosa de consumo de REST seguro

En Postman se crea una petición HTPP a la API REST segura bajo el método GET. Adicionalmente en la sección Headers se crea un nuevo valor llamado autorización en el que se coloca el token generado anteponiendo la palabra "Bearer".

Como se puede observar la petición realizada al web service asegurado devuelve una respuesta exitosa. Demostrando que keycloak y la configuración realizada en el servidor de aplicaciones Jboss EAP y en la API REST permiten restringir el acceso a peticiones HTTP.

5.Resultados

La Tabla 1 muestra el número de peticiones a la ruta http://localhost:8180/rest-app/ services/privado/Cliente/obtenerClientes y sus respectivas respuestas al consumir API REST no asegurada. Se detalla el tipo de petición, método y headers. En la respuesta se detalla el estado, el tiempo, objeto recibido y tamaño.

La Tabla 2 muestra el número de peticiones a la ruta http://localhost:8180/rest-app/ services/privado/Cliente/obtenerClientes y sus respectivas respuestas al consumir API REST asegurado sin autorización. Se detalla el tipo de petición, método y headers. En la respuesta se detalla el estado, el tiempo, objeto recibido y tamaño.

La Tabla 3 muestra el número de peticiones a la ruta http://localhost:8080/auth/realms/ Demo-jwt/protocol/openid-connect/token y sus respectivas respuestas al obtener token de autorización de keycloak. Se detalla el tipo de petición, método y headers. En la respuesta se detalla el estado, el tiempo, objeto recibido y tamaño.

La Tabla 4 muestra el número de peticiones a la ruta http://localhost:8i8o/rest-app/ services/privado/Cliente/obtenerClientes y sus respectivas respuestas al consumir API REST asegurado enviando token de autorización. Se detalla el tipo de petición, método y headers. En la respuesta se detalla el estado, el tiempo, objeto recibido y tamaño.

La Tabla 5 detalla el tiempo promedio de respuesta de servicio web REST asegurado en comparación con el tiempo promedio de respuesta de servicio web REST no asegurado, de acuerdo a los resultados obtenidos en esta investigación.

La Figura 15 muestra que el tiempo de respuesta del servicio web REST asegurado es mayor que el tiempo de respuesta del servicio web REST no asegurado.

6.Discusión

De lo expuesto por (Christie et al., 2017) se concuerda que actualmente es muy difícil desarrollar e implementar soluciones de seguridad informática middleware para una aplicación tecnológica, debido a la complejidad y costo. Actualmente existen diversas soluciones como WSO2, Keycloak entre otras que pueden acaparar las necesidades de seguridad de la información de una empresa, sin necesidad de desarrollo e integración exhaustiva. Adicionalmente se ha podido constatar que el framework de autorización OAuth2 utilizado en la mayoría de gestores de identidades permite a las aplicaciones limitar el acceso de cuentas de usuario en un servicio HTTP.

En el trabajo de (Guamán Quinche, 2011) se identifica dos principales problemas de seguridad informática en los sistemas web como son ataques de inyecciones SQL y ataques al DOM de las páginas web. Dichos ataques constituyen una amenaza ya que pueden comprometer la información y la disponibilidad de los servicios, sin embargo hasta la fecha no existe conocimiento de este tipo de vulnerabilidades en Keycloak por lo que las implementaciones con esta solución no se verían afectadas, sin embargo se debe considerar ciertas estrategias y buenas prácticas de programación como el uso de expresiones regulares o filtros en los datos de entrada para de tal manera mitigar las vulnerabilidades antes expuestas.

(ANAYA LOPEZ, 2011) concuerda que existen diversas vulnerabilidades y amenazas en los servicios web tales como ataques externos e internos debido a que los servicios web están diseñados para ser abiertos e interoperables. Al configurar los firewalls para permitir tráfico HTTP, las solicitudes a los servicios por dicho protocolo pasan a través de los firewalls fácilmente, dejando a la red interna expuesta. En este estudio se demuestra que la utilización de tokens SAML utilizados como mecanismo de seguridad puede resolver el problema de la autorización y autenticación en el consumo de servicios web. Lo que permite que el servicio web no se encuentre disponible a terceros no autorizados y que solo pueden acceder al servicio aquellos que están definidos en la política de seguridad.

Los resultados obtenidos en la presente investigación ilustran que el consumo de un servicio web sin ningún mecanismo de seguridad expone recursos sin discriminar autorización o permiso alguno de acceso, lo que exhibe una brecha y un grave problema de seguridad. Es por ello que asegurar una API REST es indispensable para proteger la información que se gestiona, en este trabajo se demostró que es imposible consumir servicios web asegurados sin haber adquirido un token de autorización proporcionado por Keycloak Red Hat SSO.

Si se considera el tiempo de respuesta del servicio web REST asegurado el mismo es mayor que el tiempo de respuesta del servicio web REST no asegurado sin embargo esta diferencia se considera como no significativa al ser tan solo 987 milisegundos, esta cantidad de tiempo de diferencia es insignificante en comparación con lo valioso e importante que es garantizar la integridad y confidencialidad del mayor activo de una empresa u organización, la información.

Es así que la estrategia descrita en esta investigación demuestra que se puede lograr mantener restringido el acceso a recursos no autorizados gestionados por una API REST con la adopción de tecnología middleware de autenticación y autorización, corroborando de tal forma que la utilización de JSON Web Token y Keycloak Red Hat Single Sign On permite proteger la comunicación y los datos de servicios web REST en peticiones HTTP.

References

Referencias

ANAYA LOPEZ, E. (2011). Implementáción de Controles de seguridad en arquitecturas orientadas a servicios (SOA) para servicios Web.

Augsten, S. (2018). JBoss EAP soll robuster und performanter werden. Retrieved from https://www.dev-insider.de/jboss-eap-soll-robuster-und-performanterwerden-a-674456/

Bradley, J., Sakimura, N., & Jones, M. B. (2015). JSON web token (JWT).

Christie, M. A., Bhandar, A., Nakandala, S., Marru, S., Abeysinghe, E., Pamidighantam, S., & Pierce, M. E. (2017). Using Keycloak for Gateway Authentication and Authorization.

El Hajj Hussein, M. (2019). Reproducible Examples for Integration with Keycloak. Retrieved from http://cds.cern.ch/record/2684669/files/CERN_SSP_Final_ Report.pdf

Guamán Quinche, E. R. (2011). Seguridad en entornos web para sistemas de gestión académica. San Sebastián: Universidad del País Vasco. Facultad de Informática.

JITTERBIT. (2018). State of API Integration. Retrieved from http://info.jitterbit.com/ rs/017-VOG-951/images/State_of_API_Integration_2018.pdf

Schwab, K. (2016). La cuarta revolución industrial: Debate.