*texto colaboración de Daniela Marques – Sensedia
La popularización de hardwares de prototipado como Arduino y Raspberry Pi baratearon el costo de desarrollo de sistemas embarcados y dispositivos IoT, permitiendo que cualquier persona desarrolle su propio sistema inteligente, como automatización residencial, control de sensores, robots, etc., con mucha facilidad.
El «boom» de IoT es reciente y, diferentemente de sistemas convencionales, en esos dispositivos existe la preocupación de consumo de energía y banda, limitación de memoria etc. y todavía hay poca discusión sobre arquitecturas que permitan evolucionar de manera ágil, segura y escalable esas aplicaciones en el mundo IoT, siendo común casos de vulnerabilidades en sistemas críticos como equipos de vigilancia, sensores e incluso monitor cardíaco de bebés. Es esencial durante el desarrollo preocuparse con esos temas y una API REST puede ser una solución ideal.
“If you’re afraid to change something it is clearly poorly designed.” – Martin Fowler
Al utilizar REST, existe una flexibilidad mayor de incrementar nuevas features, facilidad de exponer el sistema a diferentes plataformas (los clientes pueden ser apps, otros dispositivos IoT, navegadores etc) y, si utilizado correctamente, reduce la complejidad del sistema, permite incluir API Management para solucionar problemas de seguridad, throttling, validar accesos etc. e imagine las innumerables posibilidades de exponer una API de un dispositivo IoT.
Existen algunas diferencias importantes para implementación de APIs para sistemas comunes y para dispositivos IoT.
MQTT vs HTTP vs CoAP
Son comunes escenarios en los cuales el consumo de banda y energía del dispositivo son limitados, ya sea por limitaciones de hardware o por tener procesos críticos que son prioritarios. Para esos casos, existen protocolos que son más eficientes que HTTP, como MQTT y CoAP, los cuales también permiten utilizar JSON.
MQTT está orientado a mensajes y funciona como un modelo cliente/servidor pero el servidor se denomina broker. Cada dispositivo, sistema o sensor puede ser un cliente e inscribirse en un tópico:
/sensors/{sensorId}/temperature
Suponga que A y B son clientes inscriptos en este tópico y C publica un nuevo valor de temperatura en ese tópico. Los clientes A y B recibirán la notificación del nuevo valor agregado sin necesidad de realizar ninguna solicitud y, consecuentemente, ahorrando procesamiento y energía. En MQTT las únicas acciones disponibles son publish, subscribe y unscribe diferente de los verbos HTTP.
CoAP, a su vez, permite el uso de los verbos ya conocidos como GET, PUT, PATCH y DELETE pero utiliza el protocolo UDP en vez de TCP/IP. El modelo es exactamente cliente/servidor, donde el cliente realiza solicitudes a algún recurso y el servidor retorna las responses. La gran ventaja respecto al flujo HTTP TCP/IP común es el hecho de que sus paquetes son menores, ahorrando los recursos del dispositivo.
El proyecto Eclipse Ponte permite que sea posible la misma aplicación y devolver y recibir respuestas en HTTP, MQTT o CoAP.
OAuth 2.0
OAuth 2.0 es una solución para autenticación y autorización que promueve acceso a los recursos solamente para dispositivos/clientes autorizados.
El flujo funciona con Resource Owner, Resource Server, Authorization Server, OAuth Server y Client. Para acceder a un determinado recurso, los siguientes pasos ocurren resumidamente:
1) El Client debe contactar al Authorization Server con su respectivo username y password
2) El Authorization Server verifica con el Authentication Server si los datos informados por el Client están correctos
3) En caso estén correctos, Authorization Server permite que el Client acceda al determinado recurso con el access_token
Toda la comunicación involucrada en el proceso de OAuth 2.0 necesita TLS (Seguridad de la Capa de Transporte) para tener la seguridad que el client es realmente quien dice ser y encriptar la comunicación. Sin embargo, con dispositivos IoT, tenemos limitaciones que no permiten que el dispositivo esté todo el tiempo online, preocuparse con batería, realizar operaciones complejas con poco hardware, etc.
Para utilizar OAuth 2.0 en IoT independiente de TLS, es necesario usar el flujo denominado Proof of Possession.
1) El proceso empieza normalmente con el Client contactando Authorization Server con su respectivo username y password, Authorization Server verifica con Authentication Server si los datos informados por el Client están correctos. En caso afirmativo, se retorna un código de autorización al Client.
Ese código de autorización retornado sirve solamente para comprobar que ese Client es quien dice ser y no permite acceder a ningún recurso.
2) El propio Client genera una key suficientemente fuerte para no ser descubierta
3) El Client transmite la key generada anteriormente al Authorization Server junto con el authorization code e informando qué recursos desea acceder. En esta etapa, Authorization Server sabe que aquel authorization code generado está vinculado a una determinada key y retorna un access_token al Client
4) El Client con el access_token accede a un determinado recurso. El dueño del recurso verifica con el Authorization Server cuál es la key de ese determinado access_token, el acceso se permite solamente si el access_token transmitido está de acuerdo con determinada key.
¿Y en el caso que el dueño del recurso esté offline y no pueda verificar con Authorization Server aquel Client?
En ese caso, es posible realizar la validación a través de un JWT. Los pasos ocurren normalmente pero, el Authorization Server en vez de retornar un access_token, se retorna un JWT. A través de JWT, el dueño del recurso logra validar aquel Client sin necesidad de comunicarse con Authorization Server.
Para obtener más información sobre tokens en OAauth 2.0, lea Cómo verificar si un Token OAuth es válido
Cool things
MBED Device Connector
Mbed Device Connector es un servicio desarrollado para conectar tarjetas basadas en ARM Cortex-M en la nube a través de APIs sin configurar ningún ambiente de infraestructura y gratuito, soporta CoAP/HTTP, utiliza JSON y es ideal para prototipado, pero limita la cantidad de solicitudes por día y puede no ser tan personalizable de acuerdo con las necesidades.
Pingo
Pingo es una API elaborada totalmente en Python que permite la portabilidad de código para tarjetas que tienen diferentes hardwares, evitando el retrabajo. En la práctica, Pingo permite que el mismo código que se ejecuta en Arduino Yún se ejecute en BeagleBone Black, pcDuino etc. Actualmente, Pingo soporta Raspberry Pi, Arduino Yún, Arduino Firmata, BeagleBone Black, Intel Galileo, pcDuino y SECO UDOO.
Amazon y Azure IoT Hubs
Las principales plataformas que ofrecen servicios en la nube ya ofrecen servicios específicos para IoT, los cuales, por lo general, permiten autenticación del dispositivo, ofrecen un Gateway para administrar la latencia, seguridad y análisis de usos y cuentan con SDKs disponibles para conectar cada dispositivo a la nube.
Referências
https://medium.com/@AlexandraBowen/iot-is-eating-the-world-apis-and-rest-9e0321bc6cbf
https://medium.com/@AlexandraBowen/iot-is-eating-the-world-future-of-iot-a001dc263f08
https://dzone.com/articles/json-http-and-the-future-of-iot-protocols
https://nordicapis.com/why-oauth-2-0-is-vital-to-iot-security/
Leave a Comment