SensediaSensediaSensediaSensedia
  • API Products
    • API Platform
    • API Governance
    • Event-Driven Architecture
    • PCI
    • Flexible Actions
  • API Services
    • Sensedia Professional Services
  • Solutions
    • APIs para Aseguradoras​
    • Open Banking
    • Retail & E-commerce
  • Blog
  • Contacto
    • Contacto
    • Clientes
  • Carrera
  • Español
    • Portugués, Brasil
    • Inglés

APIs para dispositivos IoT

By Lucas Tempestini | APIs | 0 comment | 29 diciembre, 2017 | 0

*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.

APIs para dispositivos 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.

 

APIs para dispositivos IoT - Sensedia blog post - Internet of things

 

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/

API

Lucas Tempestini

Graduated in Marketing and Advertising at PUC-Campinas, became specialist in B2B Marketing at Unicamp, crazy about internet and technology, enthusiat of great guitar players and BJJ purple belt! :)

More posts by Lucas Tempestini

Related Post

  • Time Sensedia em Paris no APIDays

    3 Temas destacados en el APIdays Paris 2018

    By Rafael Rocha | 0 comment

    Quiero compartir aquí con ustedes algunos highlights y trendtopics que percibimos en el mayor evento de APIs del mundo, APIdays – por ahora, ¡porque nuestro APIX está arrasando! El evento ocurrió en Paris, entre el 11 y el 12/Diciembre, y Sensedia estuvoRead more

  • Modelo de Madurez para la Arquitectura de APIs

    By Rafael Rocha | 0 comment

    link para artículo original: https://www.linkedin.com/pulse/api-architecture-maturity-model-rafael-rocha/ ¿Su empresa está lista para la Economía de las APIs? Esta es la reflexión que los arquitectos y estrategas digitales deben hacer, en el caso que deseen que su empresa participeRead more

  • ¿Su empresa consume APIs? Reduzca costos y gane agilidad con Monitoreo y Caching

    By Nicholas Gimenes | 0 comment

    Muchos servicios externos se consumen a través de APIs por diferentes departamentos (Marketing, Financiero, I & D, Distribución, …) y muchas veces este consumo no es monitoreado o optimizado, lo que lleva a gastos innecesariosRead more

  • Casos de Uso de APIs para Bancos, Fintechs y Financieras

    By Nicholas Gimenes | 0 comment

    Si usted llegó aquí ya debe saber que las APIs son las impulsoras de la nueva transformación digital en el sector financiero. La competencia no es sólo entre empresas con activos y sistemas propios, sinoRead more

  • 6 errores que pueden estar en la Estrategia de APIs de su Ecommerce

    By Nicholas Gimenes | 0 comment

      La expansión de los marketplaces por medio de las APIs creó un nicho de competitividad muy fuerte en los negocios digitales. Su estructura permite reducir costos y generar nuevas posibilidades de canales con agilidad,Read more

Leave a Comment

Cancelar la respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Categorías

  • Analytics
  • APIs
  • Eventos
  • Negocios Digitales
  • Publicaciones Externas
  • Sin categorizar

Etiquetas

API API Economy API Gateway API Management APIs Architecture Arquitectura design de APIs DevOps Ecosistema de Socios ESB estrategias digitales Estratégia Digital estratégias digitals Event-driven Eventos Exposición de APIs Gestión de APIs graphql gRPC Iinnovación Innovacion Abierta Innovación Insurtech Integraciones Integración MicroServices Microservicios Modelo de Negocio Monetización Negocios Digitales Notificacion omnicanalidad Open APIs open banking open insurance Plataforma REST RESTful seguridad Seguridad de APIs Service Mesh SOA Transformación Digital Transformación Digitale

Entradas recientes

  • Black Friday Post – La experiencia de Via Varejo
  • Intégrese con VR Beneficios de forma ágil, simple y segura
  • La importancia de una buena atención de soporte
  • Optimizando Arquitectura Event Driven en Java (desde el bajo nivel)
  • La importancia del uso de métricas en APIs
  • Política de Privacidad
Copyright © 2020 Sensedia | All Rights Reserved
  • API Products
    • API Platform
    • API Governance
    • Event-Driven Architecture
    • PCI
    • Flexible Actions
  • API Services
    • Sensedia Professional Services
  • Solutions
    • APIs para Aseguradoras​
    • Open Banking
    • Retail & E-commerce
  • Blog
  • Contacto
    • Contacto
    • Clientes
  • Carrera
  • Español
    • Portugués, Brasil
    • Inglés
Sensedia